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fore;word 

The .mbrea^itig use of computers by Government and private organiza- 
tion^ for the storage and manipulation of records of all kinds — personal- 
as well as of a business nature — has placed computers anJJ the systems in 
which they reside in ,an extremely sensitive position in ^ur society. The 
needs of the* individual as well as Government and private organizations 
require tha.t this data and their resident systems be accurate and reli- 
able. These needs also r^qui^^ that this data and these systems be 
given adequate protection from threats an(X hazarjds. The establishment of 
secure computer systems is th,e way in which the >computer community as- 
sures" the users of such .systems that all of these i:equiremei>ts are being , 
met . ^ / • ^ 

, The auditing and evaluating of computer systems for adequate secu- 
ri^ty has been a natural outgrowth of this widening interest in this 
area. Controls that ffrovide computer security are of interest to both 
the financial and internal auditcy^s and has" been made a subject of spe- 
cial considerat^ion by organizations such as, the Institute of Internal 
Auditors, the American Institute of Certified Public Accountants, and 
the EDP Auditors Associtation . 

The National Bureau of Standards, with the^suppoft of the U.S.^Gen- 
ei7al Accounting Office, sponsored* ah invitational workshop in March of 
1977 to explore the subject of "Audit apd Evaluation of Computer Securi- 
ty." Leading experts in the audit and* computer , communities were invited 
.to share their thoughts and develop a consensus view on ten aspects of 
the subject. These Proceedings are the results of that meeting. ' 

To all those concerned with the audit and evaluation of computer • . 
security today, we at the National Bureau -of Standards offer this series 
of consensus reports for 'your ^consideration. The- views expressed do* nots 
necessarily reflect . those of the National Bureau of Stai:?p[arda, the U.,*S. 
General Accounting Office, or any of, the organizations that S^onso'red an' 
individual at the workshop, ^wever ,i these reports do reflect the compo-. 
site thoughts of a group that deserves your seripus attention. ^ 



*. M. Zane Thorntdn 

Acting Director^ * 
' * ') Institute for Cocoputer 

t-- * ^ Sciences and Technology 
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PREFACE 



The National* Bureau of Standards (NBS) initiated a Task Group 
within the Federal Information Prdce'ssing Standards (FIPS) program in 
1973 to develdp standards in Confputer Systems Security* Task Group 15 
(TG-15) was composed of representatives from private industry as' well als 
Federal, State and local governments. The NBS"^nvitatiooal- Workshop' on , 
Audit and Evaluation of Computer. Security was organized as one phase ^f 
a two-phase project defined by the Ta4{< Group ir\ this' important area of ^ 
computer security, Thes'e Proceedings are the result of phase one, 'The^ 
second phase will be to .adapt -this information to the needs of Federal 
agencies in the form of Vederal Information Processing Guidelines, This 
latter' effort wili be carried out jDy a working group convened for this 
purpose and will result in a FIPS publication by NBS, . 

The General Chairman ^nd organizer of the Workshop was ^Robert G, 
McKejizie of the U,S. General Accounting Office, As leader of the TG-15 
project on 'computer ^ se^curity auditing, he initiated and p^lanned the 
Workshop aYid ao-edited these Proceedings, Mr, McKenzie is an audit 
manager, at GAG and has conducted a number of reviews of computer Securi- 
ty of .proposed and on-going systems in the FeSeral Government, 

■ , / 

The General Vice-Chairman of the WorksWp was Zella G, Ruthberg of 
the National 'Bureau of ^Standards, As NBS coordinator of the TG-15 secu- 
rity audit" project , Mrs, Ruthberg worked closely with' Mi?, McKenzie on 
the planning, §cted as^ tTie Workshop arrangements chairman, and is co- 
editor of -these Proceedings, She has conducted "a wide range* of projects 
in computer science at NBS and most recently has become active^ ir^ the 
managerial procedures required for computer security, \ 

Mr, S, Jeffery, , Chief of ^he Systems and Software DiV'ision of the 
Institute for Compcrter Sciences and Technology of NBS, headed the NBS 
•staff at the Workshop, Mr, Jeffery has been active in the formulation 
of policy concerning the effective utilization of computers within the 
Federal Government and is manager of, the computer program at NBS, Thj,s 
program provided the needed technical and adminisitr^tive support for- 
this ^Workshop* * • ^ 

I would like to thank all of the particitpants in this Workshop, 
the Chairmen. and Recorders of the sessions^, and the thrfee individuals 
named above ^for the su*^jce^s of the Workshop, THe products to be derived 
from the Workshop and subsequent efforts in this area Kill have far- 
reaching,' beneficial' effects , on the use of computers throughout the 
cQuntry, . * ^ ^ " r ' 

Dennis K, Branstad 
• - '* Chairman, TG--15 ' " - 
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. 4 <? , ABSTRACT 



The ifational Bureau of Standards, with the support of the U.SAGen- 
eral Accounting' Office, sponsored an invitational workshop on "Aurdit and 
^Evaluation of Cojaputer Security," 'Held in Miami Beach, Florida on March 
22-24, 1977. it^ purpose was" to .explore .the state--.of-the-art in thi^ 
area and define appropriate subjects for future research. Leading ex- 
pert^ 'in tl:\e audit and computer communities* were ^inA^ted to discuss the » 
(SubjecX in one of ten sessions, each of which considered a different^ as- 
I pect, A consensus rep6rt was produced by each of the ten^sessions and 
^.these reports form the body of ^these Proceedings • The ten topics Ve- 
i . period on are: Internal ^udit Stamda^^ds^ jQtjaiif ications and* Training, 

Security Administration,* Audit Consid^rraxionsA Various System ^nvir^n- 
, \ ments, Administrative and*^liysical Cofitrolp, S^r^ogr'am Integrity, Datat^In- 
tegrity, Comioprfications , Post-Proce^s^g Audit Tools and Techniques, and 
Interactive 'Au^it Toois and Techniques* ' ' \ a 

' ' ' * • • ^'^^^ 
i ' ' ^ ^ ' • . < - ■ t 

.\ . ^ N • • ' 

'KEYWORDS: Audit standards; audit techniqu^^ audit tools, audit 
' t!raining,, communications security, compcrif^r controls, comput>er 

security, data integrity, -interapfeiVT audit , internal audit, post- 
, proceasing audit , program integrity,' 

• i' ■ • . ■ ' " ■ 



* . a'cknokledgements ' * " 

' . • • c ■ ' ■ ■ " 

The success of the Workshop was dependent on .the work: of^ many peo- 
ple, W would particu'larly like to take this 5pportunity to thanlTall 
the Session Chairmen, the Session Rs^^ders, and the attendees for their 
efforts in behalf of this Workshop. V/e would also like to thank the ses- 
sion coordinators Robert V. Jacpbsbn, John Pana§acos, and Thomas^C. L.owe 
'for m^aking things* run smoothly wbile the Workshop was taking place; ^Qd 
Dennis K. Branstad for pJ;iotographing scenes from^^the Workshop/ 
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] . ^ ^ 

- - . V_ ■ '/ ■ . 

' ■• ' On March 22.-24^ 1977" an .Invitational Workshop \5n Audit and- Evalua- 
tion of domputeV Security was held by. the National Bureau- bf Standards 
;(lffiS) in Miami Beach, Flori^da. The Workshop was planned and carried out^ 
-by/NBS with, the support of ' the ,IL'.S. General Accounting Of f ice .(GAO) ; |- 

• ThW Workshop is. the first bart of a two phase effort, originating 
. Within- f^sk Group >5 (.JG-^5\ of the Federal Information Pftgcessifl^j|tan- , 

'dard^- (FIPS) Program, irt th^ Computer Security Audit area. |fTfe*-g5als ot 
'. the 'Workshop were to consolidate 'the state-of--the-art^ inf9rmation avail- 
able in the field and to define areas for future research. ^ The goal 6f 
■ the* second phase of' this effort will be to adapt this information to the 

• need5, of .Federal agenci^es in the form of Federal Information Processing 
, .Guidel'i^s. It i-s expected that bhis;-iatter task vil% be carried out^by 

a w^Afilig groups convened for this purpose. - ' , ^ 

■ '-^ . • - 

'Undar-the direction of Robert G.->McKenzie of the U.S. .General Ac- , 

** " coui^ting.#fj.cfe and with Zella G. Ruthb'erg as the National Bureau^ of 

Standards liaison, an informal task team within TG-15 planned the - . 

Workshop format and subject matter. The result was a relatively • small 

invitatl'bnal topic area workshop to cover *ten non-mutually exclusive ma- 

f Jor areis of ^ncern^in computer security audit. '<• ; , ^ 

\' ' ■ ' , ' 

, With inpa^s from the tklk team as we],l as the Institute of Internal 
Auditors, the American Institute of Certified Public Accountant's, and 
the Canadian Institute of Chartered Aocountants, an outstanding group of 
session Chairmen, Recorders, and a^itendees' drawn from the audit and "bprn- 
puter communities was selected. The three days at the Workshop allowed 
• v^these people to develop the "basis for/the ten report^ontained in these 
/ Proceedings. The following mater iaVsummarizes these 'ten reports. The 

4' reports are independent *of one another and may be read ii\any. ordf r. 
/Note that the reports toward the beginning of the Proceedings are -fflOGe 
management .oriented and the later, ohes-mtajeUechnioally oriented. 

. ' ■ i ^<^TnN ON INTERNAL AUDIT STANDARDS^ ■ 

" / -r • , , • ■ . ■ 

In response to their charge* to develop a proposed statemenj; of au- 
dit standards for computer sectiVity this group first Refines the 
-larger subject of internal audit of a compiuter system, and ^t^en defines 

• computer security ^udlt. It characterizes this audit as covering aC- 

, . countability,. primarily in the areas of commance .and program results. 
, It concludes that the GAO pamphlet entitled ••Standards. for^Audit of 
. • Governmental Organizations, Programs , ^.Activities and Fun'ctions" f6rms a 
spund foundation for internal audit standards for EDP audit and that axl 
tfiat is needed are supplemental standards such as AICPA|s SAS3 to define 
•additional tasks that the auditor must perform in H computer -security 
■ audii to meet these basic 'standards. Three^reas ^re idientified for^ 
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thesi supplemental sta|!dards: . ' • ^ - . * 

/ \. Systems Development*, ^ " ' - * - * 

* 2*. OperStional Systems (Applications Controls), 

! . /.and - / : \ ' ^ 

3. Physical^ Security and General Controls. ' * 

In the area of, Systems Development, audit involvement Vould assure 
!that plans are made for controls against theft and error, appropriate 
aijidit traiis, conformity with management objectives^ and with the law, 
^^su'fficient documentation, appropriate design approval mechanisms, and^ 
.general .Efficiency and economy, ^n the area of Operational Systems, au- 
d^t would' check t^hat the application conforms to standard^s.aa^ the la- 
test design specifications, and that t^he internal , controls an& reliabil 
"ity af data are sound. In the Physical Security and General Controls 
area, Sudit would verify that .the organization structure*; the physical' 
'facilitieSji^ the. personnel management y'Hhe back-up c'^^taMlitj, and the 
software/hardwariS*- controls all, help meet mana|ement's objectives. 

The recommendations for action^by this Session were:- . 

1. that GAG review these supplementary standardsNand consider 
/ adding them to their other Standards; - ' .A • 

^ 2. that these supplementary is'tandards be reviewed arid endorsed 

by^ the Federal Ai^dit Executive Council^ ' ^ ^ 

and . ^ . . ' , ■ > 

3* that NBS, consider these supplemental standards for incKsion 

in a FIPS guideline in the area of audit for computer security. 



SESSION M QUALIFICATIONS AND .TRAINING ^ , 

• jD^response to the question, "What are the qualifications and 
, training necessary to'condj^at 3udit of computer security?," this group 
draws up an outline Qf Uie. broad body of knowledge needed to perform a 
computer security audit • Some of the considerations thatsh^pe their 
reply are that ' ' ' ^ 

1) computer security involves all cfontrols 'needed to^ ensure the in 
tegrity, accuracy) and reliability of tHe acquisition, processing, 
storing, and dissemination of information; * 
. 2) persons performing thi-d audlit should have an initial degree in- 
(but not limited^ to) such disciplines as accounting, business adr 
niini St ration, engineering, operatiQns r^eSearch,. computer scienci, 
or economics plus a solid supplementary foundation in. management , 
auditing, data processing, 'and/or telecommunications; - i^* 
3) audit of more obmplex systems* require so many of these djrscip^. 
lines Aha,t,.anr interdisci|^inary team should probably be use'd; 
♦ 4) training is availabi^ft|r can be installed in all the standard 
y Educational channels; ^ 

~'5) costs <*nnot» be estimated because there are too many variables, 
in -going, from one organization to the next; ' ^ 

.and ^ • • ' ' ^ • . 
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6) there are 4at least/three'^"levels of knowledge needed for the 

^ -work:' - ^ / ^ • . * ' \. ' * ''^ 

a) general management an"d auditing concepts;, 
'-b)data processing and telecommunications expertise, 
and ' * > > . V ' - v^"* 

^ c) a comprehensive intdgraticm of the -first two obtained . . 

' / .through further training and experience, " . [f^^ *\ 

Xhe b^oad categories in the outlii?e of the common bod^ of knowledge are: 

^1, Computer systems, operations, an<^ software * \ ^ ^ 

2, Data .processing techniques; \ . . . - / . * 

^. Management of the data processing function; ^> 
4, Security of' the data processing function; ' • . 
^{ Risk analysis and threat assesc^ent; ^ ' q j ^ 

6* Management concepts and practices.-; 

7. Auditing concepts and practices^; ^"^^ ' , ' 

8. Additional qualifications needed' to evaluate compqter^ecurity • 
A brief discussion of 'each of these categories is giVe^, The final out- 

^ line contains a listing of the major dispiplines appropriate for each 
category, * . ' ^ ■ ^ - 



ERIC 



SESSION ON. security ' ADMINISTRATION 

This session responded to the qpe;3ition, ."What aud-it approaches and 
.techniques can be used in an evaluation of the security. administration 
function?" Initially this .group discusses the ]^al basis' for* estab- 
lishing a Security Administration Funct4.bn-in a Federal > 
9rganization— the Brooks Act (PL-89-^6r'and the. ^ivacy 'Act of 1974- 
It also proposes that the Security Atiiainistratioij Function must be de- 
fined in detail so that audit of that function becomes a standard com- 
pliance type review, . The bulk of the rest .of- tl^e paper is (fevoted to 
defining the. Security Administratic^n Function',. - ^ , . ^ \ 

An important related issue, mentioned . in^ the early part of the pa- 
per conceros- the need for international .privacy Law^cqmpatibility,- 
' Privacy legislation has already been passed in Sweden and GSrnjarxy and^_ is 
pending in Norway, Denmark, and France, International organizations 
will be "finding this an important issue in the years, ta come,^ ^The ^e-*^ 
port has an Appendix outlining the Germati privacy' law. ' ' ' ' - -ti 

Some/of the important points made abou^he Se^rity Administration 
FunctiorT are that . y^^-^^^ , ^ • ^ 

^1 • 'Responsibility for safeguarding ,*an organiz^ion' s data and in- 
jforma^on resources belongs to those individuals^ having physical 
. custody and accountability for it,.'i.e, all levfels of , line' manage- 

mentL . , ' ^ ' > • 

2. Tn§ Security Administration Program is a s^aff function and 
should consist of developing overall policy an<f^ monitoring ^y^r^lX 
effectiveness; . " | . . • 

3, Planning for security administration should be carried out at ' 

-.2, 
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three management levels: ^ ^ — • 

' a) broad policy level, usirtg top management input, 

b) an intermediate ^p|[iicy level developing implementation in- 

' struGtions, 1 
' ; -c) tfiCimpXementatipn level ^^eveloping schedules and ret^ourqo. 

requirements^. X ■ • 

4, Management controls to ensure that security objectives are ^ 
achieved fit into, three ^categories— j^siici^ that* are formulated, 
at- the topf^ -procedureg for administrative, physical, and technical 
security measures,* and practices fx>r the standard management ac- 
tivities, / . . 

5, AJC)F security^ controls should 'include a) administrative safe- 
guards in the *form of contingency plans, security documentation, 
authorization control lists, program access controls, personnel 
.ru;.es; b) physical security safeguards such as area restrictions, 

^ dris^§ster back-up, storage libraries, disppsal procedures;' and c) 
* . tea^nical security in the form of a secbrity system to handle. data 
and files, program libraries, operating system(s), teleprocessing^ 
and encryption., . • . , - * 

6, Training is needed for- systems people as well as users. 



example- of a suggested security system for an on-line system 



An 

given,' . 



is then 



• The final requirements of the group are that the Audit and Secbrity 
Administration functions* shoulci be independent of one another and ^at 
the Audit function reports to the agency head, Giv^n this set^of condi- 
tions and the clear definition ^f the Security Administration function, 
the ^audit of this function is then a .'compliance review. 
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SRgSTON Of^ AIIDTT CONSIDER/\ T J£fNS IN VARIOM SYSIEU ENVIRONMENTS 

« 

The question this* session .considered was, ,"What are the considera- 
tions io be given to the audit of computer setjurity in varii^us system . 
environments?" This group identifi^es four ccmceptual modules for the 
development of an open-ended structured model 'of computer, security au- 
dit. These arev ' " . 

1, Defining three vital audits components—access control-^ accuracy, 

and "avSilability , 

[ 2, ^escribing a morphology of systems and environments: Physical 
components, system's structure, and people^* T^ie systems are 

jdescribed t)y. five identifiable c'iiaracteristics —number of users, ^ 

itypeS of service, system organization, user access,' and application 

/ mix, . ' ' ' ^ . ' ^ ^ 

3, Defining a methodology — a Computer auclit* model— which estab- 
lishes a scorecard value f§r eaoh parameter 'capable of beiiig audit- 
ed, . ^ 

k.^ Perf^rtoing a model validation by testing the model with four ex- 
* amples, ' , , , ' 
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- . This group declares that an auditor, goes through a s^t of ste^s 
parallel to thos^ executed by a design team* . J[t then /ro^^'s to out- 
line the design t^^am^ Activity , i.e. to define, requirements , objective^, 
and sensitivity; ^tp specify the physical, system, and administrative 
panameters; to specify possible^^control techniques; t.o make 'four judge- 
ments concerning^ each control — ' ^- ^ ^ 

1 . cost , , . , * ■ 

2. ef fectivenej^s in maintaining access control, 

3. ef fectivene-ss-in' maintaining accuracy, 

4. effectiveness in '-maintaining availability, 

giving each of the three effectiveness aspects of the control a theoret- 
ical score of 1 to 10 and using Sll four to make decisions on whether or 
not to use the cqntrol. The next design team' activities then are to 
select a 'subset of these contra]^ to provide the "desired level of pro- 
tectiop; to incorporate these cgJtvEnols into- the environment, to reassess 
the system, andjfe iterate until all requirements are satisfied.* The 
parallel operations performed by an auditor would be:- to review the ob- 
jectives, requirements, and sepsitivity; to determine the actual en- 
'viroriment; to identify the control techniques being used; to perform a 
cos.t ;aild effectiveness analysis, this time /ising hardware and -Software 
techniques, to give each control, its composi^te score; and. to prepare a 
report on^the findings. The group developed a tabulation sheet for 
recording these findings for any particular system. ^ The pa^er has four 
system examples on the tabulation ^heets to illustrate thp.s approach to 
coipputer security. It also points oqt that there are currently no stan- 
d^d methods for evaluating a control, i.e. giving it a score of 1 to 
,^^^vThis is the area that needs a corrsiderable ^fnount of future effort. 

:^SSIQN ADMINISTRATIVE iAND PHYSICAL . CONTROLS ^ 

This ^c^p responded to the question, "What are the audit ap- 
proaches and techniques for evaluation of administrative and ^physical 
controls in a*n ADP' environment , including contingency plannijig, etc.?"'' 
The group initially establishes the thesis that the concerns of data 
^security ari^d the r^esponsibilitiestof the auditor are complementary since 
bolA deal with ,the protection of resources within 4^ data processing 
mission. The areas of concern to the auditor all have problems associat- 
ed with them. Somp of the more important areas mentioned are 

1. the need f|:>r a' workable definition of security 

2. the need for an explicit statement of security policy * 

3. the need^for' accepted standards of good practice 

4. the heed to know what tests and, examinations are appropriate 

5. th^ need to know the hazards that a system is .sujtJ^act to. 
The remainder of the report: covers sjuggestions for the audirtor. 

First, four general areas of intere^t^ to 'the auditor are discussed 
and ^he^r^ve non-mptually exclusive audit approaches to data processing 
securffeflfcr^e discusised in detail. The four general areas are 

^1. Audit focus, and materiality— Security protective measures should 
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yield "an acceptable level of risk,"^' -The auditor should review- 
.that this is the case, particularly'for the most sensitive app}?*^- 
tions, * ' ^' , ft ' 

2'. Standards oif'^raetice and their documentation — Five references 
are'briefly discussed' for their contributions in this area.. The 
best single one is stated to' be "Computer Control Guidelines" and 
"Computer Audit Guidelines^ by the Canadian Institute of Chartered 
Accountants, ."^ • * - 

3. Security audit report — An outli<ie of a security audit report is 
given in two parts- one part addressed to higher management and the 
second to the auditee and his management, ^ ' 

■ .4*. Best traditional audit techniques — These are: ^ J"- 

Selective protection — review key resource prot^tion, 
Test — use actual tests where possible\ ' ' 

Intefview-?-with all involved employees and management, 
Technical cooperat^ives (co-op) — use talent from other 
organizations and locations; . - - ' - 

The fi^ audit approaches are each discussed, under the headings Concern, 
Purpose, Approach, and Scope, * They are: • ^ . 

1, System- Development and Maintenance Practices Audit 

2, Application Review . • - ^ 

3, Installation Security Review , * ^ 

M, Security Function (Data Base/Communication Environ- 
ment) Review ' * , * 
5. Compromise Attempt* ^ - 

The report concludes that the issues for the DF community lie in 
adapting to the new technalogie's; (increasing portability of storage 
media, mass storage, and distri>bQted systems), satisfying the need for a 
single compendium of audit concerns and techniques^ and improvement and 
change by management in programming application development and systBifi 
development, ' . : 



SESSION ON ' PROGRAM INTEGRITY . - 

This session* responded to] the question "What are 'the ^audit ap- 
proaches and technique^ for evaluation of program integrity in an ADP 
,)^ironment?" It emphasizes that program integrity must be considered 
Iv.eV the entire life cycle of the program. Program integrity concerns: 
1) correctness in fulfilling requirements and doing nothing else; 2) sa- 
tisfaction of trained user expectations*; 3.) usefulness in fulfilling an* 
intended mission; and 4) the ability to be evaluated so that a levfel of' 
trust in /the progr^ can be established, ' / , 

Program integrity assessment is a multi-dimension problem. Determining 
when in the life cycle to/auclit is one dimension. Other dimensions in- 
clude the severity of the security threat and the methods employed dur- 
ing development to achieve integrity. 



The methods /for achieving program integri^ty can be i5ut into three 
categories: * ^ ^ ^ - 

1. tfiose tbat give evidence the program is coVrect, , . 

/ -2, those that show it is robust and will perfbrm-a^dequatelj^ in the 

face of unexpected events, " • ^ , • - , ■ " 

3. those that show it is trustworttiy and <ieveloped' in accord w\th 
■ " .good pract^e, / , . . ' * / 

A discussion of methods in each of these categori€fs is included^ in the . 
pap^'r • ^ * . ' ^ " * - I 



Thi recbr^en'datio^ife from the group are:' . ' - ' ♦ 
For existing sotware: ^ * ' j\ . . \ - . 

* • !•* Be- cautious in assuming program JLntegr>xty eicists,- ^ . * ' ^ 
2. Use the limited' existing tools, guided by a careful risk , ' 
management analysis,* ^ , ; . ' 

Ifliprove physical, and ad^nistrative cotitrol^ and thu3 reduce 
- the effect of lack of* program integrity-. - . - • " 

Reduce the exploiter popul^atiori by access controls. , . * ' 
^ 5. Reduce asset ext50sure by removing assets from'the 'system 'when ' 

they are QOt din use, * , - • 

For futur^ softwa're: . ' 

1, 'Improve the program p^od^uctiorPprocess. • ' - ' ^ ' 

2, Assure program o.ntegrity compliance through the entires li'fe cy-:^ 
cle, . * ^ ' ^ ' \ ' 

' ' ' . ... .1 * I . ' " . 

For organizations^"; *^ • ' - . * 

1, Perform a self-assessment of its^hreats and its invoiv«men-t 'in 
the life cycle of. the programs it uses* 

2, Create guidelines for the development and -acquisition of ■ ' 
" software th^t is auditable for progr^ integrity, 

* *" . 

^ SESSIoS^ ON DATA . INTEGRITY • ' ^ • . 

The question addressed by this group^was, '^What are t'he audit ap- \ 
proaches and techniques for evaluation of t'h^' data iiitegrity in an ADP , . 
environment?" The group decided to limit itself to considerations of ^ \' / 
those safeguards having a direct bearing on' data integrity audit / assum- 
ing that physical, operational, administrative, and software * <,'C^ 
measures — all necessary fbr data integrity — would be handled by other'* ^ ^ 
sessions, fhi^^group defined data integrity a3 tKe state -that exists 
when dat^ i^(within defined limits of reliability) accurate, con- . 
siatent, authorized, valid, complete., unambiguaous,, anqj processed ac- 
cording to sp^qif ications in a timely manner. The objectives of a data 
integrity audit are evaluation of compliance with and adequacy 'of exist- 
ing policies and procedures, ^nd recommendations of corrective actions. 
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To achieve this objective, one needs to evaluate the lllAQwing 



areas: ^/) 



eliability, of the data source ^ 
o source data' preparation 
o data' entry controls ^ 
^"^^iP ^st^ input acceptance controls^ ' 
data validation and ''error correction " 
"o processing -specifications , . 

^ ou^ub and distribution nontrors^ 

* and . ' , .* , 

o audltability . 

The group then Outlined activities for producing a comprehensive 
audit work plan, and briefly discussed a variety pf^ methods for data ip- 
tegrity auditing. Some of those included are: 

o' checks with users on accuracy, completeness, and consistency; 

o possiblQ^^^^samplJ^r^^ 
"o parallel processing; 

o dntegrated, t^st facility (ITF); 

o System Control Test Review File (SCARF); ' ^ 

. • .0 tracing tagged transactions; i ^ ,4 

o test.d^.cks; 

, o questionnaires; ' ' .v 

O' procedural walk-throughs; " . . - 

o> aotiv^ty^^^l^^, , " ' ' ^ 

^ ' SESSION ON COMMUNICATIONS ' ^ 

' * 'This group, responded to the guestion, "Wt^f areHhe audit ap- ^ 
proaches and techniques for evaluation of communications' in an'ADP' en-' 
vironment?" They limit their discussion to guidelines for a data com- 
munication security .audit of a computer system that uses a data .communi- 
cation ne-twork. This audit applies'to the hardware, software, and pe6- 
ple, involved with the data communications of th'e computer system* The 
group recorataends that such an audit should be made on sensitive applica- 
^tions ^nd the general data communications system, with the frequency be- 
ing directly related to the sensit^-Vity qf the applications or system, 
^he general approach for this type of audit should be^ a transaction- flow 
analysis, tracking transactions both from ti^e input terminal through the 
network to the computer, and in the reverse direction (computer to t^r- 
rainal) . • • . 

A specific tool developed by the group for conducting this type au- 
dit is a resource/exposure/safeguard matrix. This matrix contains a 
list of ten system resources down the left hand'si(3e, a list of six ca- 
tegories of Bjcposure across the top and an en'dmeration of appropriate 
safeguards that might be in place for each combination oT resources and 
exposures. The auditor's job would then be. to determine what ape^he 
actual -resources of. the computer .system (terminals, distributed 
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intelligence, modems, local loops, line's, 

raultiplexo/»s/concentrators/&wit,ches , front-oua processor, computer, 
software, and people); and .to see what safeguards are in place to pro- , 
tect- these resources ^qgainst the possible exposures '(errors and omis- 
sions, disaster and cTisruptions^ loss of integrity, di^scicsure , defalca- 
tion, a'nd theft qf resources). Eacn of the seventeen safeguards in the 
report (as well as the resources and exposures) are d£fined. In addi- 
tion," fgr* each saYe^uaVd there is a statement aboat what the auditor 
should do with respect '.to his review of this safeguard. 

The paper points out its own limitations — that the^safeguards are 
not all-inclusive, will only assist in achieving security but no£ 
guarantee it,- may not apply to all applications, and orU/y reflect the 
current st^te-of-the-art> methods, ^ 



SESSION ON POST - PROCESSING AUDIT TOOLS ANIT TECHNIQUES 

The question- this group addressed was, "What are the post- 
jirocessing audit tools and techniques available or needed for the effec- 
tive use of the various system journals and lo^s in an audit of computer 
security?" The,y initially describe the general objectives of such an au- 
dit. as determining the existence, ^cope, and adequacy of controls in the 
light of level of protection required. They note the specific objectives 
as establishing the existence of uniq^ueness of transactions, transaction 
in^tegrity (completeness, accuracy, ant^ authorization controls)', prcJtjess- 
ing integrity, distribution control's, recoyerabilijby controls, and vio- 
lation controls.^ The terms "computer securl'ty^' , /'computer security au- 
dit", "post-processing * audit" , "lo^gs" , "\ools vs. techniques^', and- 
"transaction" are defined, to enhance the p-larity of the document. ' 

This group then describes-^what it considers to be the essenpe of a 
post-processing security audit . Such ah audit is always c.oncerned with 
o INPUT ' . . o * 

o PROCESS ' ^ ' • 

o OUTPUT 

and . ^ \ 

o ACCESS to any* of the above three. . * 

The objectives of a security audit 'can be achieved by looking for 
information detailed in a log on any of the al5T>ve components. This log 
'would shcJw five basic 'types of information:"^ 

1. WHO — identifies initiator of an action, 

2. FUNCTION — describes the processing activity," 

3. WHAT — identifies objects of processing activity, 
^..STATUS—refers to FUNCTION and associated iriitiator and affected 
objects, ^ 

5. TIME — gives it a date-time stamp. 
An example is given of the. security information requirements for an EFTS 
system. * . 
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Post-pr'^yeessing techniques are "then aescribed under the basic four 
components of an audit. For Access and input one would uss logs of 
successes, logs of failures, and a log continuity check. ' For Process-, 
there are manual checking , .control totals, test data, integrated test , 
faci.^ty, taggi<ig, extended record maintenance, tracipg, mapping, recora- 
pilation, parallel simulation, and" retrieval progpatlfs. For Output there 
are output Hsting?a.-*of, dispositions and author^JfatioPK listings • 

The conclusions and recommendations y<jf the group were: . 
♦ 1, hxisting software tools offer roiich but could be made. easier to^ 
use^ by , / , ^ ' 

a) fablishing a catalog of these tools for tjae auditor/ 
• ' b)* creating facilities to easily combine the use of two of 

these tools, . ,^ ^ 

2. Needed techniques are 

a) a method for maintaining th^ security of the security log, 
(Some possibilities ar-e using present operating systems, or 
using a speciaJL tamper proof recording device to record all 
activity, or a complete hardware ^monitor similar to a cockpit 

^ flight recorder), ' • 

b) higher level software to access and manipulate logs. 

SESSION ON INTERACTIVE AUDi^T TOOLS AND TECHNIQUES 

This group responded to^he question^ "What are the interactive afu- 
dit tools and techniques available or needed to permit ,on-line auditing 
of computer security?" . This session explored a subject area which is in* 
the very'early stages of deyelppment. The group defines its overall' goal 
as "The development of an auditing approach for the use of on-line or 
in\;eractive techniques to achieve performance assurance In computer sys- 
tems, "v and its specific objectives a's 

^ 1, Define the scope and requirements for^nteractive tools and 

techniques, 

' 2, Review and define auditability and control characteristics in 
computer systems. / 

3, Describe tools and techniques available a/i^ specify needed ones, 
M, Develop criteria for the use of 'these 'tools in specific systems 
environments and define ^the required .int.erfaces (e.g, with' Data 
BaSe", Operating^ Systems) , 

In ordBr to achieve these objectives the group first defines a 
number of terms, the most central one being 'interactive auditing '-an 
activity con^iat^ng of interactive audit programming and interactive au- 
dit processing,. Interactive audit for computer security is then put 
^nto the larger framework of Performance: Assurance (PA) {tlefined as 'as- 
suring that a computer system is performing its intended' functions 
within a sp^bified degree of accuracy, timeliness, and data security, 
and that it is not performing unintended functions). Performance as- 
surance is initially described in terms of the functions performed by 
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sever'al different kinas of people, lacluding the Certified Public Ac- 
countant> senior organizational management, internal auditors, the qual- 
ity assurance functiog:!, and oper-ational management. However the, PA 
function is -l^gely discussed* in terms of four activitie$: 

1. Setting PA .objectives relating to ^ ^ ^ . * 

,a) the nature and purpose -of ^ the testing, 
b) the nature of the computer system being tested; 

2. {fathering .information needed to review, evaluate, or establish' 
systems, procedures,"^ and controls; *. 

3. Performing PA analyses and evaluations su^-table for -the nature 

arid complexity of the system application; 
4. Designing and perform4.ng PA. test procedures aS' a result of thfe - 
analyses and evaluations. - , ^ ^ 

Exi-sting audit tools and techniques to accomplish the above .PA Ac- 
tivities acre' divided into two clashes, batch ancl interactive, with-a^- 
vantages and. disadvantages of each bfeing^#§ri. Available batch tools 
are utility programs,' test decks, audit modules, integrated test facili- 
ty (ITF), test data generator; snap^ot (with tagging), tracing, SCARF, 
audit software -^'ackages, and parallel simulation. Interactive tools' are 
i\udit Command Language^ (ACL) and^ ifational Automated Sbcjounting Research 
System (NAARS). The benefits oT interactive tools* and techniques ^re 
discussed. All .audit tools and techniques are tabulated by ^A activi- 
ties performed. ^ ^ 

^A comprehensive discussion of needed toolScand techniques is then 
given. They are divided into, five broad categories: 

1. near real-time error detection and correction, * ' ^ * 

2. monitoring of adequacy of controls, 

3. measurement of iiesign accuracy, 

4. program modification control, 

and ' • ' . \ 

5. monitoring gystem trouble indicators. 

This part of the report outlines a iarge number of tools that need 
development in orders to make interactive auditing a reality. These 
tools and 'techniques are also tabulated by PA activities performed. 

The broad recommendations of this group are that further delibera- 
tions and' research are required in the following areas: 

1. Specifications of design an<l, penfornaance requirements for in^ 
teractive audit tools and techriiques. 

2. Designs of interactive audit tools and techniques^for interfaces 
with operating systems^ and.datar base management systems. 

3. Behavioral ^udit research ta study audit behavior in an interac- 
tive human-machine' mode of operation. J 

4. Development- of a comprehensive audit and control theory to' guide 
PA professionals in their activities and software designers in the 
development of apprbpiate audit tools an'd techniques. 
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1. HOST WELCOIING ADDRESS . • • 



\. ^ S^ Jeffery ■- 

National Bureau .of standards 

like to welcome all of you to the^^National Buneau of Standards' 
Invitatiojial Workshop on Audit and Evaluation of Computer Security, 
Xhis will be a memorable meeting because qf the^ qualifications .of those, 
here today, as well as the broad^^scope of organizations and disciplines 
they ; represent • ^ / . 

It is interesting tp note that 33$^of*the Workshop attendees 
reprgsehtnlearly a dozen Federal agencies and organizations. The 

'Federal agencies include: the General Accounting Office, the Department 
or Health) Education, and 'Welfare, 'the Department of Defense, the Gen- 

' eral Services Administration, the Department of Agriculture and, of 
bourse, our own Department of Commerce, V 

Although we have an impressive 'list ,Qf persons from these various . 
Government agencies, I would especially like to welconje Frank S, Sato, 
the Deputy Assistant Secretary of Defense i^or Audit; Donald L, Scantle*- 
bury, the Director of the Financial and General Management ^tudies^ Divi- 
sion of the General Accounting Office; Howard 'R, Davia, the Director of 
' the Office of Audit at the General Services Administration; Donald L, 
Eirich,' Associate Director of the Logistics and Communications Division 
of the General Acpounting Office; and C, William Getz, Regional Commis- 
sioner of the Generai^Services .Administration, Region 9. 

\ Their respective experience will provide an important addition to 
the rich mixture of knowledge here today, 

" ^The remaining 67? of the attendees come from accounting firms, 
software and hardware organiz§itions , private industry, and universities. 

We havje a solid contingent from the accounting world with six firms 
representee^. There are seven software houses ^nd uwo main-frame 
manufacturers; in the university area, three U,S, universities; and in 
the private sector, twenty-two fifms drawn from suchNdiverse fields as 
banking, utiliti'es, the fuel industry, insurance, res^rch, publishing, 
a credit. bureau, the photographic industry, and law enjforcement — as 
represented by the Royal Canadian Mounted Police,- 
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A second "cut at th"e, attendee list for this Workshop can be made 
from the point ^qf view of skills and knowledge represented. The audit 
aspect of this Workshop is. govened by persons from the American Insti- 
tute of Certified Public Accountants, the Institut,ja of Internal Audi- 
tors,, the EDP Audit^)rs Association; the Association of Gbvernment Ac- 
countants, s±x large .accounting firms in. the private sector, and audi- 
tors from various Gov.ernment^ and private organizations. 

The computer aspect of our Workshop is represented by persons en- 
gaged in developing control software and techniques for industry, for 
Government, and for uni?frer'sitie*s y^ith a strong contingent of leading- 
edge i^esearchers in all these areas, 

'It should be clear from all that I 'have said that we have an unusu- 
al array of talents assembled for this workshop, 

I think Jthat this -is the' first .time that such a breadth and depth 
of ab^jlties has been- focused on the subject of audit and evaluation of 
computSr^^s^curity, ' ' . . , 

.Like to thank our Chairman, Mr, Robert G, McKenzie of the Gen- \ 
eral Accounting Office fo^ his ff forts in-giiiding the evolution of this 
'Woi?kshop, He was instrumental in selecting the topics for discussion in 
'the various s^ssion;^ and Session Chairmen, and provided constant gui- ^ 
dance in the selection of session attendees, 

' My thanks also to Mrs, Zella G, Ruthberg of my own staff who has 
worked with Bob McKenzie throughout th6 planning. She has also been 
r^^Sponsible for coordinating 'all arran^ments for finding and obtaining 
these fine accommodations, , 

Our specific interest in this .Workshop is to accumulate sufficient 
information to form the\basis for Federal' Information Processing Stan- 
dard's and G|iidelines in rhe area of audit arid evaluation of computer 
security, > ' . * / 

The Institute, for Comjluter Sciences -and Technology of the National 
Bureau of Standards has the responsibility of providing ^Federal agencieB 
vtLth standards and guidelines for data processing, and it is expected 
that the Proceedings of this Workshop will be^ the precursor to such a 
guideline, ^ v 



Considering the broad'spectrum of abilities assembled here, these 
Proceedings '-will undoubtedly be a valuable document in itself, to be 
used by all those ^working- in the internal audit ar^as, 
• • / \ 

Again, let me thank y6u all for your interest in coming, and I want 
to wish you every success in' your efforts. 



2. EDITOR'S COMMENTS ON THE SESSIONS AND THE REPORTS ' 



2.1 Some Definitions of Terms 



Each attendee was furnished a copy of FIPS PUB 39, "Glossary for 
Computer System Security," in an attempt to maintain uniformity of 
technical terms in the reports of the various sessions. A number of the 
'sessions chose to redefine a few terms and use others not included in 
the Glossary. In most of these cases, the definitions as used by the 
session participants have been included as &n integral part of their re- 
ports. The following is a discussion of a few terms considered to be 
essential. . ' , • 

Computer security audit . An independent evaluation to determine 
the accuracy and reliability of* the data maintained on or generated 
by* an automated- data processing system, (2) the adequacy of protection 
aJfforded the organization's assets tb include hardware^ software , and' 
data, from all significant anticipa^ted threats or hazaras, and (3) the 
operational reliability and performance assurance of the „automated data 
processing system. - , ' 

■ Is, 

Internal audit . An independent appraisal activity within letn^ organ- 
=ization for the review of operations as a service to management. The 
overall objective of int|rnal auditing is to assist management in at-* 
taini'ng its goals by furnishing information, analyses, appraisals, and 
recommendations pertinent to management's duties and objectives. The 
need for effective internal auditing in the Federal agencies has been 
recognized by the Congress in a number of laws, particularly th^^udget 
and Accounting Procedures Act of 1950 which requires the head ors^each 
agency, to establish and maifftain ' . > 

' internal control designed to provid^... 

effective control over and accountability for' all funds, 
property, and other assets for which the agency is \ 
responsible, including appropriate internal audit."' 





Externail audit . Frequently considered synonymous with financial 
audits conducted by certifUed public accountants. Financial audits are 
objective e3?aminations of rinanciai/statements, accompanied by the ex- • 
pression of a competent opinion concerning the fairness of the presenta- 
tion af* those financial statements. However, a broad definition of ^ 
external aucjit would simply be: An audit of any type conducted by indi- 
viduals independent of the organization under review. 
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2.2 Observations , £ % • \ • J \ ./ 

''^ ^ ■ \ . ' " ' 

.Audit and. evaluation of computer security is a very complex subject 
that must be considered from a total system perspective. It involves 
the .evaluation of. all of the controls necessary to assure computer secxi- 
.rijt.y as delfined Onder "computer security- audit" in "section 2,1, • ' 

* ' /. 

The total security system that prcyides such assurance consists of 
controls that can be grouped into various l^ategories, such as physioai, 
procedural,* operational,.. te<Jhnical, etc* However, it does little good 
to have strong -controls in one area , if the co;^tr61s in another areyei- 
ther weak and unreliable dr can easily be circfumyented • The end riesult 

could be the ^ame a disaster. In view^of this and the known int'erre- 

latiopship between various categories of controls, it is necessary that 
all controls be evalua^d prior to rendering an opinion as to the ade- 
quacy of computer security within any automate^ data processing *6ystem* 
Therefore each part *of these Proceedings should be considered *wjith equal 
weight when' developing a progr^ for such audits, * , ' , , 

, I ■ ■ ■ 

2.3 Heading the Proceedings 

^^e report's of the ten sessions are independent of one ainother and 
'ay beVead/ in any order. Note that the reports toward the ^oeginning qf 
the^ Proceedings are more management oriented while thCse toward the end 
are more technical^ly orient-ed, A detailed Table of Content^ has been in- 
cluded as an aid to locating specific materials. Major recommendations 
and conclusions of- the. sessions can be foCind in the Executive Summary at 
the beginning of these Proceedings*, The account of why the Workshop was 
held, how it evolved, ancf how^the ses*sion reports were generated can be 
found In Appendix B, * ^ ^ . * * ■ 
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PART II: KEYNOTE ADDRESS 



DONALD U ADAMS 
American Institute of Certified Public Accountants 



Biographical Sketch 



Donald L, Adams is Managing Director of 
^Administrative Services at the American Ln- 
-stitute of 'Certified Public Accountants, with 
responsibility for' internal applications of 
the computer as well as development of its 
use in the accounting and auditing practices 
of members. His administrative responsibil- 
ities include Personnel, Purchasing, Offic^ 
Management, Printin'g and Shipping. Long a 
member of AICPA, "he has served on a number of 
its committees in the computer ajce» > 'i fe,!L-^ 
eluding t'he chairmanship of the EDP Auditing. * 
Committee. He is^-a former. member of the 
Compujter Committee of the Hevi Yo»*k^'State 

-Society of CPA's. 

t • 

Before coming to AICPA June'.1973, 
Mr. Adams had for three year^been Assistant 
Directdr of Data Processing at the 'investment 
banking firm, Salomon Brothers./ Prior to that, he had been Manager of 
Computer Auditing at Peat, Marwh'ck, Mitchell &, Co. He has been in- ^ 
volved in computer auditing sinee 1960, has written ijiany articles on 
\he subject, and, has lectured extensively in -the United States," Canada 
and Europe, is Editor of the monthly newsletter, EDPACS ( EDP 
Audit Contrdl & Security ). He studied at , Massachusetts Institute 
Technology and Syracuse Uni vers.ity,' earning the B.S. tlegree Magna 
Laude from the .latter ii\stitUtion in 1959. . . ', 
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/ Keynote* Address 
Proceedings of the Workshop on Audit 
t ' and Evaluation of Computer Security 



Donald L. Adams 



1. INTROmJCTION 




^ These workshop sessionsware quite valuable. They are "brief and 
liiffited to a stated period of iime*. This,i-s a positive factor in- 
insuring that they acco'mplish their goals | Since the time is limited, 
there is a constraint on^the" ajn^ftt of debating that can t£^ke place. 
This is bound toyi:^e \ llelp. ^Iri many other, meetings „ we seem^ to he 
able to, debate 'Copicrrvirtually forever. Having a limite^d time ' ' 
period means you have a better chance of getting something done. It 
also .means that you do^ot .haye time to conduct a survey. Thank QodI 
' . ^ • $ * .* 

It seems that any time a commrttee, addresses a particular pr 
the first thing the^ want ^o do is conduct a survey. They always 
seem to be searching for that one elusive nugg^et of truth tiiat migjit 
be J)uried out there somewhere in ifHe worlds Hopefully, a survey 
might uncover that gem of wisdom.. However, I have never known a ^case 
where this ^happened. - * ^ ' " 

Mosjt of us w.ent to school Vhen the scien'tific method was'^yery 
much inrvogue. As a result, using the scientific approach to problem 
solving Jmakes us feel comfortable. Unfortun«.tely , acc9unting vand * 
audit'ii^ are not sciences. They are at best imperfect art forms. * 
In consarqnence the application of the scientific ^method is, a; mistake. 

'A group, such as the one that is attending]]]this workshop, is, hand 
picked to be a cross section of the most knowledgeable j^tappLe working 
in the particular field. It is a good bej^^tljiat there i^not 

'a single important thing goirig on in the fields of ""auditing and' 
evaluating comJ)uter secur.ity that is not known by at leasi: one jJerson 
attending this workshop. Tha'fe is where the true .""Value of tfiege 
workshops "domes into play. Knowledgeable feople get together, pool 
their information, And produce a document that will inform* others. 

".Used properly, this is a yery cost effective way of /distributing 
knowledge*. It should.be used more often. ^ ^ :^ ^, 



at' ^ - 

2. .-AN APPROACH TO THE^WORK^OP f' 



The^utline of the topics to be covered/ in this workshop includes 
ten basic areas. It is "a very ambitious program". About year ago. 



I was involved in a similar effort in regard to the-Data Baa,e 
Dire^tions^ Workshop. It might be useful to reyiew the approach we used 
in trying to meet our workshop o\)jectives .> The first hour wag spent 
in brainstorming the major topics to be covered. At the end of the 
hour we listed the projects and voted to. select the'-five^ that werq 
most important. A'time budget was established for-' each of them. If v 
we allotted^f ive hours to a topic, we discussed it Tor five hours and 
then moved on to i^he next one. The approach wprked quite well^and it 
may prove helpful to some of you over ,the next ^f ew days. 



COMMENTS ON PROPOSED TOP/CS 




I would like to offer a few comments about each of the session 
toijics. ^ 

3.1^ internal Audit Standards ^ , , 

/ * 

It is* difficulyTot certified public accountants to establish 

audit standards, is en^en harder for internal auditors to attempt 
that task. External auditors share a ciomgaon goal. They ^re locking 
to express an opinion on tjie financial statements 4t an organization. 
Internal -Q^itors have a much-more variable charter. Their role and 
the scope offNtheir activities are both established by- management . 
It is difficult for an outside group to dictate standards for the^* * 
internal audit) function. In this particular workshop the approach 
to be taken in(estab3fishing' ^andards depends* on how you* define 
security. FronNtRe material- that Was distributed in advance, it 
apijears a very broad definition will be, utilized. To the eS:tent 'that 
this gro\ip is aMfe to develop useful standards, it will be a very 
positive forward step. . , • 

3.2 QualificatJ.ons and Training ' , , | 

^^Thisds another challenging topic. It is very difficult to define 
the qualifications and training required in the field *of computer 
security since there is no accepted common -body of knowledge. Perhaps, 
a precise definition would be premature. Professional qualifications 
and standards evolve very slowly. They are comi-ng,*but it certainly 
will'be a jf^hile before a consensus 15 formed. It is very hard to 
predrct ^en we will be able to have meaningful standards for ' , ' 
professpnal qualification in a specialty such as computer security. 
The gro^^rwe^king gn this tppic should try to keep their recoramenda- 
iions at the general level. - It would be a mistake to try and ^ 
establish a^trict set^of qualification and training standards this 
early in the game. It would he better to start slow and bu^d upon 
that foundation. 



3.^5 Securit^Adininistrktion ' 

This is a relatively new area as it relates to EDP. A thorough , 
discussion of this topic should proje to be quite useful • Tl:^ere is 
a need for a definition of the duties, responsibilities, and organi-^ 
'zatioh of the security administration f\mction. While this jtnaterial 
may only be of interest to very large oikanizations , it will cer€liinly 
b^ helpful.'. We need to develop audit ap|proaches and techniques * that 
can be appli'ed to a review of the security administration functicSH, ^ 
so guidelines in this area will be parMcularly useful. 



3^^ Audit' Considerations In Various System Environments 



The environment has a decided impact on audit coi^iderations , 
but what is that impact? This is not an easy question to answer. 
TKis group will fi^fl^they have been given a very tough assignments 
Within the current state of the art we canne^fe^,,^ too definitive 
in providing guidance. To date, no one has done much, if anything, 
in" this particular area, Somoi, thoughtful consideratioii of this topic 
should. prove to be extremely helpful and will serve as a useful 
starting point for further work. ' ^ - . 

3.5 Administrative and Physical Controls. 

'* This seems to be a strange* combination of topics, Ext^rnajL 
auditors would not lump these t^o together, but it may be useful 
to consider them ^ in tandem, ' ^"^5 ^"^ prove to be a time-consuming 
task. Administrative and physical controls cqver a very wide 
^ange of top ics. T^^^^oup has been directed ^to place their emphasis 
on those areas that are not well defined in the existing literature. 
They may^ find it., difficult to identify controls that are new or 
unique, ' • * 

3-6 Program Integrity « * * ^ 

Audit ap'proaches and techniques to evaluate the security of 
operating systems, data base management systems, and application 
programs are to be covered. The members^ of this session will consider 
the problems involved in establishing integrity in these three areas. 
It is easy to consider the problems, but defining the audit techniques 
to evaluate integrity will be^quite a challenge, Tke. results of this 
group !s deliberations will certainly be of interest^ v ' ^ ' 

3^7 Data' Integrity ^ O ^ 

This IS a more familiar topic. Auditors, particularly external 
auditors, have been deeply involved in reviewing and evaluating 
data integrity f or' quiie some time^ The group has been asked to 
'identify and discuss data iiffe^rity techniques that are not well 
covered in^current literature, . This may prove to be a tough assignment 



• The literature is quite complete and it 'will "be surpris^Tng if the^group 
'can develop very much that is new in this area. . ' . 

3.8 Commvinications \ * 

' ^ ' ' \ ^ ^ 

Most auditors iack an in-depth expertise in the field of 
coimnianications security. The developments of electronic funds transfer 
systems and distributed .processing systems* will make this topic one- 
that, is of considerable importance. Even if effective i^ecurity is 
implemented in all other aspects of a system, ^the entire. ball game 
could be lost 4;hrough a data communications secur*ity fault/ Guidance 
in this area should prove to be of immen^help to the audit" comfhunity 
in defining some of its ful^ure tasks N ' ^ ' _ - • 

3.9 Post Processing Audit Topis and Techniques 

o 

A gresct deal of information is recorded on the journals and 'logs 
maintained by most of today's computer syst^ems. Auditors face a 
major problem in determining what -information is available and 
deciding how to get at it and .use it to accomplish and audit. The 
group- has been aske\i to address the topic of the need for new -techniques 
in this area. They^may cont:lude t-here is little -need for new techniques. 
Most of the itools that an auditor requires are available. They were ^^^^"^ 
developed for use by systems personnel. The auditor needs to develop^ 
a familiarity with what is availa'ble and ^o gain experience in its ^ 
use. The group addressing this topic would accomplish a great deal if 
they are able to highlight the 'areas jiuditors should exploi*e an:(i at 
the same time, provide guidance as to ttie tools they might ^ploy. ' ^ 

3.10 Interactive Audit Tools and Techniques ^ • ' ^ 

In this particular ^rea, the needs <pf the internal audfitor are 
quite different from those of the external auditor. Internal ^ , 
auditors usually work with more of a managerial emphasis and they 
are more likely to have a > need for oh-l«ne analysis of data. CPAs 
on the other hand, usually perform their work as of/ a particular 
point in time. .Their needs are usually more static in nature. How- 
ever, that may change. The growth of EFTS 'and dWistributed processing 
may make interactive auditing 'a more important area. B6th ^hterna3> 
and external auditors will be interested in the deliberations of , 
this group. 

.SUMMARY ^ < ' 

The sesfeion theme. Audit and Evaluation ^of Computer Security, . 
is a timely one. The topics that have- been proposed for discussion 
are all of current interest and deal with afeas that are^ of importance 
to the audit" community. To date, the known financial losses delated 
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to data security failures are quite, small, 'However , logically, these 

v^^^osses are bound*to increase. Consideration of the topics outlined 

for^this workshop will provide a better basis for defining our current 

problems and developing the techniques we will nee^/U) cppe wit^ ah ^ 

expanding 'tecl^nolpgy. ' 
• s • 



<5» 



PARTJII: INTERNAL AUDIT STANDARDS 

Chairpersdfrv William E. Perry ♦ 

The Institute of Internal Auditors 

Participants: , 



Howard' R. Davia 

Qeneral Services Administration 
S. Jeffery 

National Bureau oft^tandards 
Fred L. Lilly 

Liyy & Harris, CPAs 
Gerald £• Meyers 
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Kenneth A. Pollock - * ^ 

U.S^^. (Jgheral Accounting -Office 

Frank S,..Sato 
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L.^ billy, S. Jeffery^ Frank S. Sato * 



Note: * Titles and addresses of attendees can be found in Appiendix A. 



' EDITORS* NOTE 



A* breif ^b ioqraphy of the Session Chairpersonf follows: 

Mr. Will^iam E. Perry is the -Director of EDP and Research for the 
Institute of Internal Auditors and serves as staff liaison for the In- 
ternational Committees on EDP Auditing and Research. Prior to joining 
the Institute, he was Supervisor of Corporate Computer Auditing for 
Eastman Kodak Company. He .has alsq held positions with Arthyj:^You'ng^& 
Company, ^Ft. Richie, and Price Waterhouse & Company, ^^jla graduate 
of C^larkson College, holds efe^MBA from Rochester iDStitute af Technology 
ar>d a MBl ffom the University of Rochester. He is a Certified Public 
Accountant (NY) and a Certified Internal Auditor. He is a member of the 
Computer Services Executive Committee and the Auditing Advanced EDP Sys- 
tems Task, Force of the AICPA, a member of tRe Board »of Directors of the 
American .Federation of Information P^rocessing Societies, and past com- 
mittee chairman of the GUIDE International Pl/1 Committee. He was a 
professor of data, processing at Monroe Community College. His most re- 
cent publications include: "Pre-Occurrence Auditing--Building Control 
Into .the. Audit Program, ".' Bank Administration (Jan. & Feb., '7^) and nu- 
merous contributions ta EDPACS on subjects of £DP audit and control. 



The charge given to this session was: - 

INTERNAL AUDIT STANDARDS: Develop a proposed statement of audit 
standards for computer security considering (a) the role of the 
internal auditor, and (JtQ application of traditional audit stan- 
dands. ^ ' 

JComputer security is a very complex subject that must be considered from 
a total system perspective, ft involves all the controls necessary to 
ensure (1) the accuracy and reliability of the data maintained on or- 
generated by an automated data processing system, and (2) the protec- 
tion of the organizational, assets to include the hardware, software, and 
data from ajl anticipated threaits" or hazards. * 

"This sessio.n is to consider the responsibilities of the internal auditor 
in evaluating computer security throughout the developmental and opera- 
tional life cycle of an automatic data processing systemi The AICPA's 
Statement on Auditing Standards No. 3 entitled, "The Effects of EDP on^ 
the Auditor ^s Study and Evaluation of Internal ControV should be con-^ 
sidered for use as a departure point for this session. 




The consensus report thart follows was developed and reviewed by the ma- 
jority of the membership of^this s&ssion. r 
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Supplemental Standards for Internal Auditor's Expanded 
Role in Reviewing Computer Systems and their Development 

A- Consensus Report 

William^E, Perry, Fred L, Lilly^ D, L, Scant! ebury,/ 
j(en Pollock; T, Q, Stevenson, Frank S,. Sato ( 

1 . INTRODUCTION ' . ' 



1.1 Aiftomated Systems Effect on Environment 

^The computer has substantially altered the methods by which data * 
processing systems operate and are controlled and audited. The oppor- 
tunities for personal review and clerical checking have declined as. the 
Collection and subsequent uses of data .are Changed, The changes- are 
the result of moving from manual procedures performed by individuals 
familiar with both the data and the accounting process to. high volume, 
automated techniques performed by individuals unfamiliar with both the 
data and accounting practices. 

The introduction of data processing equipment frequently requires 
that the recording and processing functiorjs be concentrated in depart- 
ments that are separate from the origin of the data; It may, however, 
eliminate the Reparation of some^of^the responsibilities that previously 
characterized th^ record keeping function, A trend toward the integra- 

. tion of operating and financial *data into organizatioij-wide information 
systems of data bases also eliminated independent records that might 
previously have provided a source of comparative data< At the same 

.^time, such-integrated information systems can become thre basis for more 
vital and timely management decisions. 

Computerization has reduced substantially the time available for 
the review of transactions before their entry into the accounting 
records. As Snresult, in poorly controlled systems the opportunity 
for discovering errors or fraud before they have an impact on opera- 
tions may be reduced, especially in the case of real-time and data base 
systems, Thi-s-has increased the importance of intei^fal control pro- 
cedures [1], It also affects the work the auditor must perform. An ^ * 
important aspect of this work ia, reviewing the adequacy of computer 
. security, . r ' ^ ' ' 

1*2 Computer Security Defined ; .^.„^ " 

Computer security is a very complex subject that must be considered 
from a total system perspective. It .involves all the controls necessary 
to ensure. (1) the accuracy and reliability of the data maintained on or 
generated by an automated data processing system, (2) an appropriate 
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degree of protection of the organizational' assets to include the hard- 
ware, software, and, data from .all significant anticipated threats. Or 
hazards, and (3) the economy and efficiency of computeT operations. 

Computer 'secilrity does not include (1) the justif icatioQ of a 
computer system, .(2) the full^ range of meeting all management objective's, 
and .(3') determining arr acceptable level of risk for an (]|M||^ization,\ 
but all are areas^ f or audit involvement. ' .'^^m^ 

K3 ^Discuss^ion of Audit In)?blyement in Computer Security 

The- concept of accpi^tabil ity^. is inherent in government and fion- 
government audits. Any audit could encompass' the threfe. elements bearing 
on accountability, which are: 

1. . Finance and compliance - . \ 

2. Economy and efficiency 

' 3. Program results [ ^ * ^ - . 

From the .standpoint of the auditor ^reviewing security, the elements 
of both compliance and program results are within bounds. (Efficiency 
an^ economy may be. adversely affected by a tight computer-secyrity 
requirement.) There may be specific standarc^s or regulatory require- 
ments governing security aspects of an ^operation which should be k 
reviewed for compliance, and in evalua1;ing the program results of an 
operation, security may be an important factor. Similarly, in audits 
performed by CPA firms and the GAO, attention is givento the adequacy 
of control over assets, and this may wetl involve the security controls 
over information held by the organization. Internal auditors should 
be concerned^ with the adequacy .of control of organization-held infor- 
mation. ' ' -3 ' ^ 

^A separate auditing standard Per se to cover the auditor's, wnrk in 
this area. is not warranted. However, another mechanism is needed to 
draw the auditor's specific attention to the problem. of computer ^ 
security and make him- aware. of his responsibilities. * The mechanism may 
^injplude items such as a commentary, clarification, or interpretation of 
existing standards. . * ' . ^ ' 

. . The A^ICPAfused this means when it issued Statement ,of Auditing 
Standards (SAS) No. 3 '''The Effect of EDP on-^the Auditors' Study'and . 
Evaluation of Internal Control." The basic/CPA audit standards 'which 
have served so well without' m&difi^ation^for so long were not changed 
with the advent. of the computer but the SAS ampl if ied'and interpreted 
the standards as it related to EDP; We have chosen to use the t'erm 
' "supplemental., standard" i.n discussing the expanded role of the internal 
auditor in this area. 



1,4 Changing Auditor Requirement ^ 

When internal auditors function in a computer^'zed environment,/ 
their audit responsibility needs to encompass the following: 

K ^Provide guidance to data processing and user personnel ^ 
/for creating the mechanism for audi table ^systems 

2* Determine that internal controls io computerized appli- 
cations are operative and effective by reviewing and 
testing ttose^ controls, . . * - 



<' .2.0 SUPPLEMENTAL STANDARDS fOR COMPUTER INTERNAL AUDIT WORK 

V 

2 A'- General . , * - 

A computerized environment does not createj^ need for new audit 
standards. The'current internal audit standards as set .forth in the 
GAO pamphlet "Standards for Audit of Governmental Organizations, J 
Programs, Activities, & Functions," are basica^l.ly appropriate for ^oidits 
of the data processing function. What is needed are supplements to' 
those standards that' specify the additiCfnal t^sks the auditor must 
perform in a computerized environment to meet the baeic s^tandards. 

Three areas have been identified for the purposes of su[^plementing 
those standards. These are audit involvement iq: 

1, Systems development 

2, Operational systems (application controls). 

3, Physical security and general controls, , - . 

2,2 'Supplemental Standard for Systems Development . , ^ 

The. internal auditor shall be involved in the development ^of new 
datji prQcessiag systems or significant mbdification of existiag oqes 
with the objectives cf seeing that scich systems: ^ • • . 

1. ' Include the controls necessary to .protect agsTthst theft ' 
- and' serious error • • . 

2. Provide the audit trails needed for^fifanagpment, auditors, • 
and operational review- ' / ^ 

3. Faithfully carry out' the policies management has prescribed^^ 
for the system " « * . ? ^ ' * 



4. Will provide an effic*fent-and economical system . 

" ' 5, Are i«n conform ity with applicable legal requirements 

6. Are docum6nteci in a manner that will provide an understanding 
of the system' required' for maintaining and auditing the system (t 

2,2.]. bormientary ^ - ' . 

^ the system development process includes the definition of ^proces- ^ 
sing applications to be carried out by a computer,* design of the pro- 
cessing steps to be followed, determination of the data input and files 
that -will be reqyired^aVvd specifications for individual program's 
input data and output. \ ^ 

Auditor involyement is important in the design of an application. 
It is needed t>ecause the design fnust provide for necessary control pro- 
cedures and produce the reports and data files which. will be needed -for ^ 
audit purposes after the system becomes operational. 



Requirements for an -EDP system should be >&t4blished by management 
and it is the auditor's responsibility to determine whether or not these 
policies are being carried out in the dfesign and whether or not the 
design conforms with applicable legal requirements. Jhis will require 
the auditor to ascertain the natyre of the requirements set by manage- 
'ment, and v(hether or not the requirements are being met. 

. 'The ^ditor should ascertain that an appropriate approval process 
is being followed in^evelopment of new systems and making modifications 
td existing systems'. In doing this, the auditor should consider, the need 
for approval of syst^iTu4esi§n by data processing management, user groups, 
and other user groups whose data and reports may be affected,, - 



The auditgr should also .determine whether or not management. rem^tfes' 
documentation sufficient to define ttie processing that must' be performed 
by programs in the system, dat^ fi^les to be processed, rep.or1;s to'^be 
prepared for users,, operating instructions for^use bv comput^of)erators", 
and user group instructions' for prep^iration, and control of^ta. The 
auditor should arlso^ ascertain whether or not management policy provides 
f6r, testing sufficifent to give assjlirance thai relianc^an \>e pjaced in 
the system before thet sTystem is used for^production^ifiirposes. ' , 

' The auditor should review provisions for iecurity^ required by man- 
agement to. protect data .against unauth6rized>t(ccess and modification. 
The auditor should^ also consider whether We benefits of the system jusr 

. tify its costs whenever the benefits cajj oe quantitatively measured*. In 
all cases, the auditor. shoald be alert to whether the system design will 
provide for an econpmical and efficient system and should .""^^ves^ate 
insta'nces in which it appears mye economical or efficient metno!ii% can 
Be used, ^ ' 



After reviewi'n^management policies, the auditor *sJiould examine 
approvals, documentation, test f^esAjHs, and cost studies and other data, 
to .determine the extent to which management policies'are being followied. 
The auditor should keep a close associatipn with the system 'during the' 
development ^'phase [2^ but should not become a part of the design team- 
except to th3 extent of' recommending controls--in order to maintain 
proper objectivity. * • - ' - 

The auditor should report in writing on both the adequacy of the . 
^policies and the extent to which those policies are being followed as 
determined by the ^auditor'.s examination. The auditor shjould specifir 
calTy. comment on all findings which require corrective action and should, 
to the extent possible, s^mit recommendations .for appropriate action". 

2.3 Supplemental Standard for Operational Systems (Appl icatiiop Controls) 

The internal audi tor, should review'the installed data processing 
applications tp determine reliability in processing data in a time^,^ 
accurate, and comjDlete manner. ^ ♦ 

Auciif objectives should 'be to: ^ 

1. Determine whether the'instal^d application ccmforms to stan^ 
dards and the latest approved design specifications, an^ 

2. Disclose possible weaknesses in the installed applicatiori 
r through' periodic audits designed to test internal control'^' 

and the reliability of the data produced. \ 



2.3.1 Commentary 



The transition from mechanical da'ta proc^sing (MDP) to electwnic - 
data processing (EDP or ADP) occasions 'the need* for revisioYi in tradi- 
'tlonal audit standjirds. More specifically, the complexity and far- ^ 
reaching scope of EDP systems require that the internal audit give . 
greater attentiof\ to th*^ system whiqh processes data, as well as to the . 
data; the theory t^e^ng that, tf the system is secure, the data processed 
and reported will be reliable. 



Supplemental standard one deals with the internal auditor* s involve- 
ment in the development of tW system specifications for the purpose of 
assuring that computer security has been adequately cons1dered--with 
an appropriate risk analysis-^and tjiat*the more traditional .interna! ^ 
controls Qver^data processing are included. 

Audit compliance with supplemental standard two provides assurance 
that the approved specifications, with all built-in internal controls, 
etc., have been installed as intended on specific applications.. 
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It further provides that the auditor institute period^^internal^ 
agdits designed 't& probe the installed application fOr weaknesses, , 
changed circdmstances in risk exposure, etc., with the, intervfenon of 
stimulating corrective modifications of specif ications, 5nd /improving 
the installed applications. In these periodic audits, th/lnternal 
auditor's consideration of internal controls is particularly important . 
Also, the. auditor must be mindful, when conducting periodic tests 6f 
the installed system, that th^re are no guarantees that the system will 
continue to xiperate in accordance with the latest approved specifi- 
xat-ions. ^ ^ ^ * ' ' , 

. As a part- of the testing of reliability of data produced, the 
^auditor will normally examine supporting documerjtation for selected 
transactions and test the clerical accuracy of the manher in Which - 
transactions have be'ea entered and summarized and to test compliance 
with control procedures. In addition, aurlitdrs may wish to test 
selected data files to identify possible excep^on' conditions and \ 
accuracy of data conversion or capture. If the'data records are 
maintained in machine-readable co^ition, the ai^ditor should where 
appropriate, make use of computer assisted audit techniques in testing 
data records. P . ' • ' 

Because of the significant potential for fraud and other irregu- 
larities in computer systems, the internal auditor must be alert to . 
the potential of fr^d. Although auditing for fraud should not I 
necessarily be the prim-ary objective, the current environment dictates 
that detection of major frauds shjould be one of the. objectives ^of 
internal auditing. ^ ' • 



2.4 Supplemental Standard for Physical Security and^4neral Controls 

The,^.internal ^auditor should be involved in review of the general 
controls present in data processing systems to assure that their exis- 
tence and operation are in'accordance with management direction and ^ 
legal requirements^ an.d are operating effectively to provide security 
over the*'data being processe^l. 
> ^ 

2.4. T Commentary , , ^^"^^ ^ * * 



, The auditor should distr«g[ui sjn between general. EDP contrpls, which 
are normally applicable tp al 1 p^efcessing being ^carried out within the 
installation, and application controls (covered in Section 2.3), whi^h 
may v^iry between applications and are therefore reviewed on ^n indivi- 
dual 'application basis. In reviewing general controls, auditors review 
and evaluate .controls in several areafs, and consider the 'effectiveness 
of the general controls in performing the review of applicatiori^ontrols 

Authority and responsibility must be delegated within the.or^ni- ' 
zation* in" such a manner that the objectives of The oVganfzation can b^ 
m^ with efficiencj^ and effectiveness. The auditor should review the* . 
^Organization, delegation of authority, responsibilities, and separation 




of duties in the' organization to determine whether or not functional 
lines oY authority are designed to meet the Organization's objectives, 
and whether or not the separation of duties provides for a relatively 
strong level of internal -control . Separation of duties shoul^provide 
for separation bel^ween program and systems development functidfr^, com- 
puter operations, control over^nput of data, and control group respon- 
sible for maintaining application controls. 
. \ * ■ , * 

In rev.iewing the .separation of duties, the auditor should evaluate 
the control strengths^ and report -on any weaknesses resulting Vrom 
'inadequate separation of duti^es. The separation of duties may be . . 
enhanced^ by policies requiring periodic rotation of duties and mandatory 
vacations. The auditor should alio review Whether^ such policies are 
being followed. ' ^ 

» ' , , ' ^ 

Adequate physical facil i ties and other resources (such as ade- 
quately trained personnel, supplies, and power) are necessary fot^ the 
organization. to meet its processing objectives. The auditor should' 
.review these facilities to^ determine whether or not the organization 
.has adequate facilities for meeting its needs. 

Personnel management, ^including supervision of personnel, moti- 
vation of personnel, and professiogal development Is an integral part 
of the successful management of the data processjng function. The 
auditor should review these policies, to ascertaiTi whether or not the ^ 
. necessary management policies exist and determine whej:her or not they 
are properly followed. 
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The audfcBr should review provisions for physical' security of the 
computer Hardware, computer programs, data files, and person?tel to 
ascertain the extent of security being maintained. This review should 
include not only the computer equipm'ent pre'sent in the central proces- 
sing facility, but also extends to computer terminals and other^erl- 
\ pharal equipment. In reviewing physical security of. computer hardware, 
'the audi^tor 3houl(J:>consider the extent to which there are adequate 
contingency plans for continuity of processing in the event of a ^s- 
ruption of data processing functions. This should include not only 
provisions for. hardware backup but detailed plans for making use of 
bafkup equipment, transporting personnel, pr^graw^, forms, and data 
files to an. alternate prgcessing location, and other contingency plans 
necessary for this mode 'of operation. The auditor should also consider 
the extent tq^ which this contingency pJan Has been exercised. 

In reviewing .physical* security over files, th^ auditor should de- 
termine whether or not data and program file libraries are mairltained by ^ ^ 
> personnel who dp^not have access to computers ari9 ^computer programs, 
whether or not the li4)rary is secure, whether or not computeV opera^^s 
- and other personnel have access to the library, and provisions for 
bacl<up of files (including^ off;:site backup). In the case' of files nor- 
maTly maintained on-line, 'the auditor should consider the extent to f 
which these files are protected by autfioriza^tion cqntrols within the 
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operating system and whether backup copiers of files are maintained on a: 
rfegular basis^. As a part of the review of procedures for maintaining , 
backup copies of iFiles, the auditor should'^review* procedures for 
ensuring that backup files are properly identified, labeled, and conr 
tents verified to ensure that the backufi^medium is complete and accurate 

Since compter systems are most often*control led by systems soft- 
ware and'particularly operating systems, and since systems softvvare , . 
provides for file hand1ing*capabiliries, multiprogramming capabilities, 
fil.e Icibel checking, and many other authorization controls, the systems 
software is an integral part of the control over computer processing. 
The auditor should be aware of the types of controls which the 
operating system and other systems -strftware can exer.cise and should 
ascertain the extent to which those controls . have been implemented. ^ 
As a -part of this review, the auditor should be aware of the fact'i:Kat 
, personnel responsible for maintenance of the systems software, ,and 
other persons with the 'ability to make unauthorized modification's^ to 
this software, may either intentionally or'-accidental ly cause specific 
Control 'features'within that software to become ineffective-. 

Computer hardware frequently has ,capa5il i1?ies designed' into it, for 
detection--of erroneous conditions related to hardware malfunctions 
rather than., program malfunctions'. The auditor should be aware of t 
extent^to which th6 installation relies^upSn fhese hardware controls, 
the exte^nt to which the operating system? util izes these^ control s , cind" 
^ the manner in which hardware errors detected in a systejn are reported 
\ within the ii^tal.),^tion as well as procedures for taking corrective 
action. x'-^-^^^- - . ^ ^ 

Z.S'^'^ther Audit -Reqwijements r > 

Th^^auditor shot^ld ^rev^ew the, organ.iz^^ion's economic justification 
and analysis for^ pracureifient of >all data processing equipment. This 
wvll incl^l^k^^ough reylew,^f the costCbenefj^ analyses developed 
^iDyi. the dcPta p/h^§ss^f^^ s.^ff oin, conjunct! on ^v/ith uSers of systems that, 
7 are {o be ^' ' ^ ' " ' ' 

should encom 

equipment beinf J^rchased^^is y^^f^'t commensiirate 

probabil>^ty of CT^osure or los?. F^r exa'mpf^i ^it^ay; be thc(t,the 
• requirements to compty^i th, trie Priiapy. Ac|^*m&V. Jiec6s$i tate adoption of* 

special technique^ to ^eveht accid^tarof -in^efftto^aT d of 
, data. This may tl|p acconlpl ished nnlPnumt?er -df^wSys^^ chosei} 

should be that which is most cost effective foV the intendea^purpose.. 

3.0' RECOMMENDED COURSE .(J^'aAiON^ : ' 

Thj^uditor should review the organiza^tion ' s ADK system' acquisition 
\ document for i^s ^standards. -Jhes^ specifications tijen ^should be com^- 
A pared tetany applicable ones of the organi|^^n and to wha^ is actually 



implemented on. the opeVat.ing equipment and software. Any deviations 
should be documented by an approved waiver or otjier release. 

The fcJllow-ing three^ actions are suggested for fostering the 
acceptance and implementation of the previously stated three supplemen- 
tal internal auditing standards. f 



That GAO review' these standards and ^consider modifying- 

their standards pamph^let accordingly, or issuing 

separate supplemental material encompassing the 

supplemental standards. . ' . 

' # 

Thd't the supplemental standards be presented to ^ 
*the Federal Audit Executive^ Council for review- 
and endorsement. 

That NBS consider these suppleineN;al standards 
in preparing FIPS guidelines for systems development, 
opera.tiona1 systems, physical security and general 
controls. ^ " 
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PART IV: QUALIFICATIONS AND TRAINING 
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EPITORS^ 'NOTE 

• ' : • * ./ , 

A brief biography of the. Session Chairperson /oTlows: 

Mr. 0, -Smith is an Assistant Director of the Logistics and 
Communications Division of thejfaited Stated General Accounting Office ^ 
in Washington, D,C. has. oveV'" 20* years of broad and ih-depth q^perience 
working with alT„ levels of operating and^management personnel within 
Federal, state, and local governments, and private industry. He is. 
responsible for planning, directing, coordinating, and^participating in 
wonld-wide evaluations of information handl ing' operations* involving 
administrative, scientific, and military applications 6f computers. His 
work has* concentrated on assessing all aspects of information handling' 
iricluUing system and program project .planning , mcinagement analysis, 
, design, implementation, and .operation on a world-wide basis. During the 
past 10 years^ he has .focused on a wide variety'of different systems and 

/programs including but not limijfe^^to command and control, payroll,' 
accounting, logistical, and. management information applications*. 
Previously he. specialized in assessing the performance of individual data 
processing installations. His degrees are in Accounting (California 
State UnTversity-Fresno, B.S. ) and in Business Admini*stration and Manage- 
ment Information 'Systems (The American University, M,B.A.). He is a 
Certified Infernal Auditor (CIA) and member of the Institute of Internal 
Auditors, 'the Sociejty for^Management Informcition Systems^ Military Opera- 
. tions Research Sgciety,- and the EDP Auditors Association^ Inc. His most 
recent pertinent publication, y/ith HI J. Podell and EL. Knowles, is 
^Management Auditing oAjComputer Operation's: ^A Tutorial , n4w York, IEEE, 
Inc.,' 1976.--^" ' 



^The charge' giyen to this session was: 

. ^ .. * ^ 

QUALIFKATIONS AND TRAINING : What are the qualifications and 
training^ecessary to .conduct audits of- computer security? • 

The firjst general^ auditiigg standard of the AICPA is^as follows: 
"The examin^^on is to* benDerformed by a person or: person^^haviog adequate 
technical training and proficiency as an auditor." (SAS No. 1, section 
J50.20). SSS -No. 3,*' para^graph 4, exoands .on this standard by stating that, 
"Si tuattoj;ys^ involving the morp complex EDP applications ordinarily w^ 
requi r'e^t ha't the auditor apply specialized expertise in EDP in performance 
of the necessary audit procedures." 

The task of this session is, to identify an-d define the *pecialized 
^%j(pertise necessary to conduct evaluations of computer security together 
with the training and experience needed to achieve the appropriate level 
of expertise. ' Consideration should be given to the full spectrum of 
controls from the evaluation of simple' physical safeguards to an analysis 
of the protective features of system software. ^ . ^ 



The consensus rep9rt that follows was developed and reviewed by 
the entire- membership of this session. 
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^ JNTRODUCTIOf{ ' . > ^ 

The computer is rapidly becoming\one of our most useful tools. 
, In. the slightly more tKan two decades since, its introduction, the 
computer has made a profound change in manyi facets of our lives. It 
assists us in predicting the outcome of our elections; it guides our. 
astronauts in space to'cpmpensate for man's relatively slow reaction 
time; 1t controls the, flow of our traffic on the streets, on rails, 
and iathe air; it is used to help diagnose our ills; forecast our , 
weather; compute our bank balances; and hundreds of other chd^es which 
we could not even undertake before its advent.' » o , • 

Predictions on. the future use of the computer are many and varied 
because the ingenuity of man knows no dimensions of time when dealing 
with the possibilities of pressing back. the 'frontiers of "his ignorance 
Since the expected growth in the useof^the computer will contine to 
be nothing less than phenomenal, managers and other us^rs will tend 
to become much more dependent- on the computer than th^y hav^ been in , 
the past. ^As these individuals become more* dependent 'on the computer,^ 
ppportunities for its misuse arid abuse will ^so increase. As t]ie 
opportunities for computer milsus'e and abuse 'increases, managers and 
those individuals who will audit arid evaluate computer operations, ' 
particularly computer security, must be highly qual ified.and well* 
trained; These individuals myst be* familiar with the symptoms .of 
potential disaster so that efficient and effective corrective action 
plans may be- initiated , implemented, and maintained "before their*" 
computer systems become.a nightmare of error and "financial loss. In . 
addition, these individuals muSt be famijiar with the methods used to 
protect data from all anticipated , threats or hazards. 

For these reasons, the basic question 'addressed during this 
session of the workshop was "What are the qualifications and training 
an individual needs to condtict reliable audits of compiiter secur-itV?" 
Specifically, this task consisted of identifying' and defining th6 
specijalized expertise necessary to properly conduct evaluations of 
^computer security together with the requisite training needed to 
achieve that level of expertise." Stated more simply. What is the 
common body of knowledge needed to do this work? . . - m 

"considerations associated with • ■ ' * ■ 

developing- a common -body of knowledge 

For our purposes, the panel considered computer security from 
a total system perspective; that is, computer secut^ity involves all 
the controls necessary to .ensure the -integrity, d,ccliracy, , and- reli- 
ability 0/ the dcfta that is an integral part of an automated datci 
processing system. This perspective includes all the controls 
established over the acquisition, prQcessing, storing, and dissemina-, 
tion of information'. The panel terof^Ved. their consideration with the 
knowledge that they were' unaware of any foolproof system of evaluating 
computer' security Vmt will prevent an unauthorized or illegal, inter- 
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vention or penetration of an automated data processirr^ system by a 
sophisticated professional and technically qualified intruder. 

When considering-the appropriate jevel of expertise necessary to 
conduct these audits, the panel first attempted to identify .the common 
body of knowledge that an" individual must have before becoming involved 
in thiStwork and then gave extensive consideratirfn to.,the complexities 
of the environment in v^hich the irfdividual would condupt the work. The 
panel assumed that the individuals') conducting these evaluations could 
h&veH'heir basic education and experience in any generally recognized 
discipline such as, but not limited to', accounting, business adminis- 
tration, engineering, .operations research, computer science, oj^ 
economics* Each of these disciplines already has a specified body. of 
knowledge identified or associated with it. Since individuals with 
varyifi'g backgrounds and experience can be expec|:ed to conduct these 
evaluations', the panel could not assume that everyone undertaking this 
work would be a fully-qualified professional auditor* Regardless of 
an individuals' basic education and, experience^ audits of computer 
security ^^niand a solid foundation ^ the concepts and practices of 
management and auditing supplemented by a solid foundation in the 
fundamentals of data processing and 'telecommunications, including an 
appreciation of hardware,^ad software capabilities and^imita-tions- 
Depending on the type, nature and scope of the/audit ,^n individual 
wiill require varying degrees of knowledge and experience in computer 
operations, software performance, and information flows into, through, 
and out of the automated data processing function/ The more complex 
the system being evaluated the more comprehensive technical knowledge 
will- be required. For example, if a major segment of |;he audit is 
•to ascertain the integrity of a computer progran^i or a,seri,e§ of 605^- 
pute^r programs the auditor, among oU^er things, .should be thoroughly 
familfiar With the severity of the potential or reaN threats that, can 
be mounted against them. As outline^ in P'^rt VIII of ^the proceedings,: 
these threats. include- but^may not be limited to the following:. 

A. Accidental disclosure ' ^ 

% • ^ 

1. Natural failure of either or both hardware ancj software 

2. Human error , ^ , , ' 

B. Casual unauthorized access ^ 

1. Browser discovered flaws ^ > \ 

♦ 2. Exploiter (intruder) seeks flaws 

Del tbe rate' attack . ^ , 

K Thief creates flaws (plants trap doors,^ modifies code) 

2.. Conspiracy (the conduct of a planned attagkO ' / - 

3. Irrational employee 

Frequently the skills needed to conduct this type of 'audit do 
not reside with a sfngle individual. In this Situation multidisci- 
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plinary audit teams could be used. A multidisciplinary team contains 
all the skills and experience needed for a specific audit. The multi- 
disciplinary team approach has been used very successfully by both 
governmental and* n/jn-governmental organizations. 

< 

^ In addition, it was the panel-'s view that they should- not overly 
concern * themselves with " who will conduct the audit" and tha-t they 
should concentrate their efforts on identifying the common body of . 
Ifnowledge needed to do the work. Further, ^he panel did not concern 
themselves with " who would^provide the training ." It was the panel's 
vtew that universities; colj^^eges; the,Xivil Service Commission; the 
Interagency Auditor Training Center; the^ Institute for Professional 
Education, Inc.; and a myriad of other institutions and professional 
organizations either have or could develop courses^, seminars, or 
workshops tha-t would meet: the training and educational needs included 
fn that common body of knowledge. • 

Finally, the panel did" not attempt to ascertain .the costs involved 
in developing the needed* level of expei^tise because .too many variables 
are involved,^ For example, ^ th^ costs associated with developing the 
needed fevel af expertise will vary substantially depending On whether 
th^ organizaTTcJTrr^ develops, the capabil ity -in-liouse by training their 
own employees, partialTy develops the capability in-house by^training 
a few selected employees and^ supplementing .this capability t)y tempo- 
rarily hiring the additional expertise from a source outside the 
oV^ganization, or hires, either tempdrarily or on a continuing basis, 
the, needed expertise from an outside source such 9S a consulting firm'. 
$ince each organization and each individual will have different ^ 
training heed*, an organization must develop its own program to obtain 
and mairttaig the^pmmon body of knowledge needed to effectively audit 
computer security. Perhaps ^a major concern here is not how, much does 
it cost to develop ^he needed level of expertise, but whether the 
organization can afford not to develop it in thejigh't of the in- 
creasing number of detected and reported cases of computer misuse and 
abuse. • . * " iff ' 

Whfen developing the common body of knowledge needed* for ^audi ting 
cgmputer^ security, the panel was confronted v/ith two basic problems. 
First, there i.s the problem of enhancing the basic knowledge and 
experience of " those^ wfio will conduct t|)e audits; and second,, there is 
*the problem of determining the extent pf the .technical training needed 
by each'individuciT participating in thfe audit. .^Experience has shown ' ^ 
that th^re are at least three levels* of knowledge required for tjiis 
work. -There is a general level of knowledge required in the disci- 
plines of management and auditing concepts and practices. Individuals 
graduating from a recognizfed university or college with a degree in 
business administration^r accounting'will usually have reached this 
level- of knowledge.*^ These individtiafls' wil T ^fefijenai.ly Isck a solid ^ 
foundation in the fundamentals of data^ processing and telecommuriications 
and will have to acquire this knowledge^tRrough additional ti^aining. 



The. second level of knowledge requires an indivi<iud.l to develop 
a solid foundation in the fundamentals of data processing and tele- 
communications iiicluding an appreciatfon of hardware and software 
capabilities and 'limitation. An individual graduating from a recog- 
nized university or college with a degree in a discipline such as 
computer science will normally have attained this level of knowledge 
Such an individual may lack a solid foundation in management and 
auditing concepts and practices^and will have to acquire this knowleit§e\ 
.through additional training. ^ ' 

The third level of knowledge involves the development pf a 
comprehensive technical k^wledge and the related experience to audit ^ 
the .more sophisticated as'pects of a computer system. For example, 
this level of knowledge .would be required ^when evaluat^ing the vulner- 
ability of an operating system .(monitor, executive System, etc.) for ^ 
unauthorized access by a bro\^ser or skilled exploiter seeking flaws 
in the system. ^ * , , 

With these reqliirements in mind, the panel outlined the common . 
body of knowledge and the" related qual ifications /and training they 
believed to be necessary to conduct reliable audits of computer 
security. The outline beginning on page 4-11 has' been preceeded by a' 
brief description of the importance of each part of that body of 
knowledge. 

" * For purposes of guiding the reader the outlJne has been divided 
into eight parts as follows: 
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1. Computer^ systems, operations, and software - 

2. Data Processing techniques 

3. Management of the data processing function . 

4. Security of the data processing- function 

5. Risk ana^lysis and threat assessment ^ ^ - 

6. Management concepts and practices 
7*' Auditing concepts and practices 
8. Additional .qual tf ications needed to audit computer 

security ^ ^ 

1. COMPUTER SYSTEMS, OPERATIONS, AND SOFTWARE . . 

*> 

The topics^,Covered in this section are intended to provide a broad 
theoretical foundation necessary for an individual to understand the 
interrelationships and interactions Qf all parts of a computer system. 
The foundation-provided by these topics will give an individual a. 
familiarity with the way computers operate and the interrelated and 
essential function of software. These. general principles may be 
applied to any type of system regardless' of whether it is a bat^h, 
interactive, on-line or distributive isystem. 




I. DATA PROCeSSING TECHNIQUES^ . 

Dramatic advances in data processing 'tecliniques have taken place 
within ttie past two ^decades and each year brings still faster and more 
efficient methods for processing\la,ta . .'Programming* languages have 
proliferated, data management has become more efficient and file . 
processing techniques have made it possible 'to store and retrieve^vast 
amounts of data. This rapid evolution of data py^esslng requires an 
individual not only -^tt) have a bas-ic understanding of data processing 
techniques, ^t to maintain currency in this rapidly changing field.* 

The topics in this section cover, in a general way, the essentials 
of data processing techniques. They cDver the.' techniques currently 
in use in the 'f ield^and must^^e maintained with an on-going program 
of education because of the speed with which new developments^ are 
taking place. - • ^ , - , 

3. MANAGEMENT OF^ HE DATA PROCESSmG' FUNCTION- 

- < ^ . " f 

Good management of the data processing function is one of the 
key ^elements in providing reliable security of computer operations. 
In addition to being responsible for day-to-day operations, these ^ 
managers must also concern themselves with a myriad of other details 
ranging from the physical layout of their, operations to the reliat>il- 
ity of the ^software used to process data^* The importance of these 
tasks cannot be overemphasized. The interrelationship of these tasks 
and their contrifc^ution to thej management of on-going programs must be 
understood by -the auditor. ' , , ^ 

The topics in this section int'rodQce the "auditor'* to the basic - 
area§ of responsibility associated with managing the data processing 
function. These topics al^o assist the "auditor'^ in "placing the data 
pijocessing function into appropriate perspective within the organi- 
zation as a whole. In this respect the conjputer.is the processpr of. 
information not the creator or user of information at least in a 
managerial sense. Finally, these topics' will help the^uditor under- 
stand the. contribution this function makes j,n the management of on-* 
going programs. ' ^ ^ 1 

V. SECURITY PF THE DATA PROCESSING FUNCTION • ' ^ ^ ' • 

Although there are no security^ techniques so fo&l'proof that they 
will prevent a determined and technically skilled intruder from^pehe- 
trating a comput&r system there a/e. certain measures th^at can be faken 
to ,discouragi^penetrjtion. These safeguards will vary from installa- 
tion to installation Qepending on a number of factors such as the 
sensitivity or classification of the data, the' clearance level* of 
personnel, and perimeter control to x\m^ a few. An individual must^ 
be familiar with security techniques as well els the sensitivity of . 
the data in a computer system t(f be able to majke reliable evaluations 
of how adequately the data is being protected. . The development , of a 



remote access capability Tor computer sys^tems^ has 'added to the/ 
difficulty of maintaining effective security/ Part of an individuals'* 
task will be to assess the adequacy of 'securit^y for all components of 
a computer system, V ' 

The topics contained in the outline are intended as a starting 
point, a listing of those security measures that should be used. This 
listing is not intended to be exhaustive of those measures only;il- 
l^strative of ' them and shoiild be used as ^ base ori'which to devise 
new and more effective methods and to build a greater knowledge of 
'.this subject, - ^ * - ' 

5, RISK ANALYSIS AND THREAT ASSESSMENT ' 

'Managers and individuals evaluating computer operations. must be 
able to recognize the symptoms of potential disaster. Knowing the^ 
probability of the occurrence of a particular threat is a major factor 
in evaluating the type and nature of the security procedures t~hat will 
be most ^effective against it. Threats may come from any direction 
such as natural -hazards (floods or fire) 'or personnel who may acciden- 
tally or deliberately interfere with the proper operation of a comp'uter 
system. In order to be able to evaluate security techniques and 
procedures an individual must be able to assess the extent of damage 
that" could result from a disaster. Thus-, an individual ^should have a 
basic understanding of risk analysis techniques in order to make 
realistic assessments of potential damage. ^ 

Jhe list- of .topics .in this part of the outline are intended to 
provide the basic understanding of the risk analysis techniques needed 
to do this work effectivety. * / 

6. ' MANAGEMENT CONCERTS AND PRACTICES 

Most authorities view 'the task'of managing slightly.differently. ^ 
Perhaps this difficulty is due to the different environmental situations 
in which they have worked or perhaps it is due to their own tempera- 
mental characteristics which have led themXto develop certain, met hods 
of managing which,' for them,^have proven toXbe effective. ^ ^ : 

' ^ ^ ^ , ' / 

Part of the difficulty al so ' may. be due to the *fact that^ the art 
and science of managing has,, been undergoing consideraliW change since 
mid-century. Mathematical and statistical concepts, the computer, 
and the developing' behavorial sciences, - to name a few, have had a 
tremendous, impact' oni the concepts and methods of managing. There are 
no simple formulas or pat a'nswers for managing. Managing is 'much too 
complex a task for t'hat. However, even though authorities view the 
task of managing dif^ferently they are unanimous ' in their endorsement 
of the topics associated With the task. Those, topics have been in- 
cluded in the panel's outl ine of the common body .of knowledge needed 
to audit computer security! ^ 



7. AUDITING CONCEPTS AND PRi!\CTICES . ' . • ' . ' 

^ The techftiques of auditing and the related topics form the 
foundation'^or conducting^ evaluations of computer security. Auditing, 
per se, is almost as* old as civilization. It was used in a^ncient 
Egypt, .the Roman Empire, and,,of course, the great mercantile estab- 
lishments of the Middle Ages, The common areas of audit action 
throughout, its history haVe been examining, verifying and reporting. 
Auditing has become a key factor in controlling every kind of organi- 
zation and its importance^Jias only increased since the advent of the / 
computer. For example. Jack Brooks, Chairman, tommittee on Government 
Operations', House of RepresentatiA/es recently stated .that the lack of 
utilo^tion reviews was one'of the ba^c problems in ,the Federal 
wGovernmeht^ , * ^ " ^ • > j 

Since the advent of the computer,^ the potential threats to^hich 
information can be subjected, whether 'by accidental disclos^es, y 
casual l?ut unauthorized access or by deliberate attack have increa/ed 
tremendously\ Thus, the need to continually audit computer security 
cannot be overemphasized,- . . , ' ' 




Oy I ^d IWUIIUU.UILAll III l-llt; j-'l IIIV«I|^I^«^ vauvj ^iva\^\«i\^>.^ w. ^.nm^^ i i . . ^ v^.. — - 

sentiiaT ingredient to the team conductTn'g evaluations of computer 
' security, ^ ^ T * 

^\ . . , . . , \ — . , . 

8, gASIC QUALIFICATIONS NEEDED . ,v ' , 

• - ^ TQ EVALUATE COMPUTER SECURIYY - ^ 

The qualifications identified by the panel reprfesen-t those 
experience factors an j"ndividual should possess in addition to a solid 
foundation in management, auditing concepts and practices, data 
processing, and related telecosnmuni cations, ^ 

It was the 'general consensus of the panel- that an individual's 
basic education and experience must be supplemented by approximately 
one additional academic year 6r equivalent of education in the subjects 

.considered ta be the essential components of the common body of 
knowledge needed for this .work. This, additional education represents 

^ about 400-500 classr^pom hoUrs of effort. Fqr purposes of comparison, 
each classroom hour was considered to oe 50 minutes in duration, A 
one semesterrthrejB unit college course would meet three times each week 
for. 14-16 weeks. Such a course would represent 42-48 classroom bours 



ERIC 



^Administration of Public Uw 89-3€6 Procurement of ADP Resources 
•by the Federal Government," Thirty-Eighth Report by the Committeeon 
Government Operations together with Additibnal Views, House Report 
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of work, Al60, it may take an individual one to five V^ars of on-the- 
job training or practical experience in auditing computer security be- 
fore they become highly efficient and effective in this work. ^ 

SUMMARY 

. Since the computer is rapidly becoming one of our most useful 
tools , and the predictions on its future use are many and varied, it 
becomes increasingly important that managers, and- other users are 
able to rely on the products it produces. As these individuals 
become more dependent on its use they will. tend to rely more heavily 
on the information provided them by individuals conducting audits of 
thj^ir computer security, so that their computer operations will become 
an ally rather than*a nightmare of^error and financial loss. For 
these reasons the Individuals conducting t+iese audit's must be highly 
qualified and well trained. The common body of knowledge outlined 
below is intended to be a basis for developing the needed level of 
expertise. > . 
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OUTLI'NE 

' COMMON BODY OF KNOWLEDGE . . " 

NEEDED TO AUDIT COMPUTER SECURITY 

f ^ t 

1. • COMPUTER SYSTEMS, OPERATIONS, AND SOFTWARE ^ " # ' 
' 'A. Theory of systems (as applied to information systems) ^ { 

B. Theory of computers ' 

0. Theory of data 'comrnqni cations * • 

2. DATA PROCESSING TECHNIQUES ' ^ ' . 

A. Information structures 

B. Programming languages 

C. Sort and search techniques 

D. File creation, maintenance, and interrogation 

E. Storage devices ^ ' • • 

F. Data manaqSment systems - " . ^ — I 

G. Fntegrated systems > - ' 

H. The'^dynamics of^ developing, modifying, and maintaining ^ 
computer software ^ - 

3. MANAGEMENT Ol^ THE DATA PROCESSING FUNCTION *' ' 
■ A. Organizational structures ^' 

B.*, Personnel selection, training, ajid management * . » 
C; Operating and organizational pol icies ^nd procedui^es 

Computer operations ^ ^ ' . . , - • 

Analysis, design, and programming functions 

4. SECURITY OF THE DATA PROCESSING' FUNCTION . \ ' ^ 

A. The computer center o ^ * . ^ - / 

B. Remote sites ' " - ' 

C. / Systems including .operating, application, and tele- . j 

commuiti cations software \ ' . - / 

D. Policies and procedures ^ . . ; 
Personnel , - ! , 

P. Data handling ^ ' 

G. Recovery capabilities ^ ^ \ ^ - < 

H. Tests of internal controls - ' . - i - 



5- RISK ANALYS'IS AND THREAT ASSESSMENT . , ; 

A, Physical facilities ' ^ '\ - ' i 

/ . B. Remote sites ^ " ' ' / * • 

' ' C- Software ; * , ^ ' ^ '1 

• D. Information , * , ' 

' • , ' ^ i 

6- , 'MANAGEMENT CONCEPTS AND' PRACTICES \ 

A. Management tasks, responsibilities, practices, and ethics 

B. Business administration .'^ ^ * 
C* Principles of organizational structures * - 

D, Concepts of general management . ^ - , ^ . , 

E. Management or the human resource 

/ ' 4-11 ^ 
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AUDITfNG i;ONCEPTS AND PRAClicES ' ' ' 

A, Introductory accounting # ' 

B, Intermediate accounting 

C, Advanced accounting ' ' o 

D, Cost^accounting - ' • , , 
£• Municipal and governmental accounting 

. ADditing . ' . * ' - 

'** , • 

ADDITIONAL QUALIFICATIONS N£EDED TO AUDIT COMPUTER SECURITY 

Individuals selected to conduct audits of computer 
security, in addition to the common body of knowledge, 
outlined above, should have the following tiualifications: 

1. Sufficient fxperience to be able to plan, direct, 
and coordinate au.dits of large complex functions, 

• activities, or 'programs, 

2. 'The ability to assign tasks to individuals on the 
team and to identify the specific disciplines 'and 

^ expertise needed to perform the work, arid 

3. The ability to (Conduct* conferences and to prepare, 
present, ^■and process the report describing the 
results of the work. ' - . 

'- , ' ■ ' . 
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EDITORS' NOTE . : '' ' ' . 

A brief biography of the Session Chairperson follows: ^ 

• Mr. MalcoTm Blake Greenjee is an Assistant Vice .President in ^he 
'Comptroller's Division at Citibank* Hi's responsibilities .include the 
"development of corporate policies and standards fqi? data center con- 
struction, operational «risk analysis,, physical ^nd communi cation -s^cu- 
"yity, and privacy. He is also reTponsible for aasessing'risk and the 
development and emplacement of procedures to offset new operational', 
risks. His career began in research and teaching at Purdue University 
in 1556.^ He was associated ^with Johns Hppkins ^University from 1957 - 
1968 in positions including Senior Physicist, PVogfam Manager for sat- 
ellite navigation equipment for Pqlaris submarines, and Program Manager 
at' the Applied Physics Laboratory for a variety of systems. . He served 
on ,the staff of the Mitre Corporation and as a 'faculty member at Ad- 
vanced Management Research. Since joining the Citicorp organization in 
1569, he has held positions as Program Manager responsible, for all as- \ 
pects of installing a world-wiwde automated payments system and Manager 
for all technical activities of Xiticprp's subsidiary. Transaction Tech- 
nology - East. He recejved his BS in Physics and Mathematics f^om 
Purdue, with graduate s1:udies in Physics at Purdue and Maryland. He re- 
ceived his MBA^in Finance and Administration from George Washington 
University. He has published several books a^d holds several patents. 



The charge .gvven to this session was:. 

r ^ * . " 

SECURITY ADMINISTRATION : What' audit approaches" and techniques can 
• be used in an evaluation of the security administration function^ 
e . . 
A security administration function h&s ^^been. establ ished in a nulnber of 
organizations to ensure the efficiency and effectiveness of the physical, 
procedural, and technical controls within an information processing 
system. Such functions have been established at various organizatnonal 
levels Bnd assigned different. resppnsibiMtifiS. Some are staff and 
others line with either a" centra] i led or- decentralized concept being ^ 

employed. " ' • , ' ' ■ 

' ' '' . " 

THis session'is to define the duties and responsibilities of such a 
function in a large organization and its most effective prganizationa I 
structure. Further, the audft approaches, and techniques to be used in 
e^ci'luating such a- function s*i6uld be^ identified. ' \ . " ° . ' 



The following Consensus report was written and reviewed by the entire 
' group. ^ - ' ^ V ; , . « 




Security Administration 
A Consensus Report 



David L. Costello 
"Linwood M. Culpepper 
Donald L. Eirich 
Thomas Fitzgerald , 
-M. Blake Greenlee 
Wallace R. .McPherson, Jr. 



1. INTRODUCTION 



1.1 General > ■ 

H 

Federal I^nformation processing Standards (FIPS) are 
coordinated and issued in accordafice with the provisions 
of the Br6oks Act (PL 89-306) to provic^e^^uidance for 
inform^ation. processing systems within U*S. federal govern- 
ment (and related agencies) in are!t*s such as , , 

- safeguarding^ the system, , . 

- providing for continuity of operations, and^ 

- safeguarding the infonaation being pj^pcessed .by ^ 
the system. ^ 1 

Legal requirements for tUe handling of personal .information' 
are imposed by the Privacy Act of 197A . This law may be viewed 
.as an embodiment of the desires of U.S* citizens to have certain 
prudent measures' put in place to safeguard t-heir implicit right- 
to-privacy. Organizations falling under purview of the Act 
tend to be very large and decentralized. ThiSiTpaper describes 
one method of coping with compliance with thes^ public wishes 
expressed by law, implementation of a Security Administtation 
Function. The implementation described is based on standard- 
ADP auditing requirements utilizing the technology base provided 
by the Federal Information Processing Standards. 

Given a well defined security administration function, the 
audit of that function becomes a standard, corfpliance type review. 
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1.2 Privacy Legislation 

1.2.i .The Privacy Act of 1974 ^ 
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Public Law 93-579, > knoTO as the Privacy Act of 1974 ,' was 
enacted intp law to protect the privacy of the 'collection of 
^increasing amounts of personal information. This individual 
data is being aggregated in the face of increasing availalbility 
of personal information made possible by technological improve- 
ments and the data requirements of an expanding governmental 
, structure. Agencies falling within the purview of • this statute 
are required' to establish appropriate administrative, technical 
and physical safeguards. Agency rules for carrying out these 
requirements^ are defined in the Privacy Act of. 1974 (5 USC 552a) 
Implementation of these rules is being accomplished by many 
agencies/departments by adding management structure - at each 
organizational level at or above^the dat.a center user, -The 
structure^-performs the Security, Administration function , 

/ / • ^ ^ ' 

1,2,2 Laws in Other Couiycries 

The United States/is but one of the many countries that have 
passed or are^'considOTing public and/or private sector pri- 
"^acy legislation, particular, legislation has passed in 

o • Sweden ' ^ ' 

o Gefmany, (Federal and the State of Hesse), 

'Imd is pending in 

o ^Norway ' • 

o ' Denmark^, apd. ' " ' 

o France 

Implications on systems design that must be acjdress-ed be- 
muse of the extra-territorial features of these laws include 




r 



trans^-border information flow ^ ' 

national sovereignty issues 

liability issues for interruption. of information 
'flow in time or in anticipation of war, etc. 
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1.2.3 International Privacy Law (Compatibility 

The Council of Europe (with U.S. State Department and the 
Office of Telecomnmnicatioqs JPolicy) has begun an effort to 
harmonize requirements of conflicting laws. /l€ is hoped that 
this harmonization by treaty may occur in thevnot-too-distant 
future to alleviate the systems implications^ inthe. present 
(and pending) environment. ' . ^ 

While the security administration function is implicit 
in many foreign laws (as in "1974"), the German law explicitly , 
requires that a "Federal agent for the Safeguarding of Data" be 
appointea and provided staff to organize, manage, carry out and 
report on security admin-is tration. Private sector firms must 
have a similar structure.. Because of the similar requirements 
of the German Law and the Privacy Act o^f 197A and the clarity., 
of definition qf 'the function, duties, etc, of the "agent" 
within that law, a precis^f the duties of the "agent" is attached.- 

'a • 

1.3 -Organization of this Report 

" ^ This report is organized in three chapters and one 
appendix. ^* . " ' ^ ^ 

-Following this Introduction chapter,^ Chapter 2 (Security Adminis 
* tration) discusses the planning, management control, ADP security 
duties and' functions of the security administrator.' Cftapter 3 
(Auditing -the Security Administration Function) recommends the organi 
zational- requirements for the audit funct:k)n and the audit approach 
to.be used. 

The appendix contains a precis of some pertinent Require- ' • 
"ments of the Federal German privacy law. 

2. SECURITY ADMINISTRATION 'PROGRAM \ / 



2.1 Introduction • >^ " 

■ - 

The concerns e^^pressed in Chapter I have given rise to the j . 
need for the organization function of Security Administration in 
Fedjeral Agencies (This may be relatively new for many? Agencies) . ^ 

\ ■ * • 
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While Security Administration includes the traditional concerns 
for data integrity and protection of the organization's informa-*" 
tion resources from modification, loss or destruction, it must 
also concern itself with safeguarding the information from dis- 
closure or improper use, ' Thus, Security Administration should 
constitute an integrated' program for protection of data in the 
organization's custody. We^are here concerned with the prin-* 
ciples of Security Administration applicable to ADP systems. 
In general, a separate Security Administratipn function may be 
practical only in large organizations. ^ In smaller organiza- 
tions, the function may be combined with other functions and 
jobs. 

The se4 ion panel members believe tfTat the responsibility 
for safeguarding the organization's data and information 
res9utce^s should be the personal responsibility of individuals * 
hav^fc: phvfiical custody and .accountability for it# Moreover, 
the t^^fAcy Act of 1974 imposes a personal liability on any 
officer ^nd employee, with* criminal penalties, for improper 
and wilful disclosure; Thus, ye believe that security of 
infbrmation i^^roperly a line responsibility, extending up 
axid down the chain of command » To segregate this ,responsi- 
bility from other custodial, processing and supervisory 
responsibilities, and plac^ it ♦solely upon a separate security 
admiriistration entity, seems patently impractical except 
perhaps in unusiial circumstances. 

It follows then,^ that Security Administration! should 
be a. staff function (independent of the DP line organization) sup- 
porting management at appropriate organizational levels and 
the central office. Security Administration should be 
responsible for developing overall policy and monitoring, on 
a continuing basis, the overall effectiveness of the security 
program, . . , \, . 

2.2 . Planning by ham 



Planning lor security administratr^n is carried out at tjiree 
levels within the oi?ganization. At the rh^^est level, broad policy 
statements are developed which address sucrKis^ues asl 

9^ ] 



^Note: Viewed in this cont^xt^ 'Security Administration' pis 
used throughout this paper is probably a misaomer 'and might 
better .be designated Security Program Administration," 



o What are the steps which must h-e taken prior to the ' 

approval of an ADP ii>s-tallation? 
o ^ How are exceptions to established policy granted? 
^o How is compliance with -established pglicy determined 
* initially and during" the life of, the installation? 
How is policy maintained and updated as a result of 
operational experience? 

^•At'^n intermediate^ level in the organization, more detailed 
instructions which implement the policy are developed. These 
instructions address such issues as: * ' 




» o- What factors' must be considered in perfpraing the rislc, ' 
analysis "for an ADP system? Of these factors, which 
are to be taken as input and therefore immutable aud 
which can be taken *as output? 
o What arie the checkpoints ^ in the implementation of/a 

system and what documentation mu^t be completed at each* 
checkpoint? 

o , What types of reports, a^e required, who prepares the 
reports, and who received the reports. Reports may he - 
required for various levei^s of security breaches, uFor 
example, each level of breach ^may require a report 
to a different level within the organization, 

o Who within the organization is responsible for each 
aspect of security? These aspects include personnel 
screening, audit ti;ails analysis, security breach 
reporting, etc. ' < ^ * 

At a lower level within the*^ organization, the actual implemen- 
tation of/i'nstructio'ns is accomplished^ At th:^ level, the func- 
tions perfor&ed include preparation of: 

o a schedule of -implementation of instruction, and 
.0 estimates of the resources required for implementation, 
* ■* * 

2,3 Management Control ' * 

Management control consists of the exercise of those controls 
which are traditionally necessary to en^re that the security objec 
tives of the organization are achieved, including: 
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Policy - the statements of management objectives for: 

1 

o the/ protectit)n of organisation interests, 

o organizational data, 

o ADP resources, and ^ * , * 

the prevention oi abuse of these resources, in an efficient and ^ 
cost-effective manner'. They should provide clear 'direction in ' 
such matters as: , ^ 

Q what information is to be protected, 
o the levels of .protection to be accorded, <, 
o • what officials have authority 'to disclose^f release^ 
'information and to whom, and 
* o disciplinary measures for violations, etc.^ 

Such policy should generally be formulated af. organiza- ^ 
tional levels above the Security Administration function or at 
'the least, with full participation of , top management. The 
policies will comprise the basis for the security program. 

Procedutes descriptions of the processes and the instruc- 
tions for carrying^ut management objectives. They must be suf- 
ficiently detailed for implementation, a^tr subordinate supervisory 
levels, "of those administrative, physipal^and technical security 
measures and controls described in the succeeding section. They 
should include the nature, 'timing and recipients of reporting and 
or exceptions thereto. Procedures' should not be lin^ited to the 
execution of the ADP function, but should extend to the security 
data and ADP respurces .employed' by org^an^atiopal users of ■ these, 
resources. Such procedures shoulti be disseminated only after 
review and concurrence by the Security Administration staff. ^ 

Praatices - such other activities that* are .dictated by 
traditional management principles including: . 

o .adequate supervisory review or control, 
*o employee activity monitoring, * • 

- o quality control^, ' * \ 

a investigation of known or suspected violations of 

the system, and - * ' 

^ initiation and enforcement of ' disciplinary actxLons. 
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ADP Security . . ^ 

2.4.1 Administrative Security 

The security administration function must yinclude the res- 
p^gnsibility for development and maintainance or administrative 
safeguard standards, including: 

o Security Ijnplementation Plans based on analyses of the . 
, • existing physical, technical,, and administrative safe- 
guards, and consideration of determinations by system 
managers of 

■.A ' • ■ 

^ - ^'the vulnerabilities^ f tH^eir data and resources, 

^nd - J v/* ' 

. - "^he protection necessary to safeguard against; 
these vulnerabilities^ 

Plans must detail the actions, resources and scheduling 
necessary to itaplement necessary addi^jLpnal safeguards, 

o Contipgency Plans that show the 'action to be taken when- 
, ' ever an error^ unauthorized disclosure or violation of 
privacy safeguarLd procedures is detected. The plan must 
- cover notification and where appropriate, recovery or^ 
' corrective action. 

o Disaster - Emergency Processing Plans which include the 
' capability of protectihg and recovering all persona'l^data 
for which the facility has a safeguard and "back-up res- 
ponsibility* Xbe plan must provide fpr continued com- 
pliance with all security Safeguards; 

o Facility Security Profile Docvpentajiion which 'documents 
* in a single file: , . • * 

procedures to b^e followed by all personnel and ^- 
organizations working for or interfacing with the 
facility, 

^ » ^- location and format, of all securily/^^cords such 
as logs and audit trails, 
- resillts of all internal an4 external security ^ ' * 
inspections , ^ 
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- results of any risk analysis performed, ^ 

- copies of the facility security implementation 
pla^i, and * ' 

- copies Of any contingdffcy backup and disaster plans 

o'.' Authorization Control Lists which include 

- lists of pllrsons authorize^^ to enter the facility, 
authorized terminal users, and 

- ajLithorized terminals. ) 

All lists must be maintained current. 

o ^Programming -Modifications^ Testing And Validation 
Controls which require; / 

- restriction of data and system specifications to 
only those individuals who have a "feeed-to-^ow*', 

- procedures to control modifications which .require 
testing before -any program changes become opera-^ 

' tional, , , ' " ^ 

- testing of new systems. or mojdif icatiojfs to systems 
' " using simulated test data, 

validation of furictional adequacy and r&liability 
of a system before- .the system is put into opera- 
. tion, and ' - . . 

- modular separation of the duties of analysts and' 
* programmers (when the staff size permits). • 

o Personnel Management Rules to ; e 

- 'establish authorities and responsibilities, 

- develop security awareness ^nd other ^naployee 
""itivolvement programs for tbe purpose of 

J creating a positive' operational atmosphere, and 

- determine that adequate evaluation of potential 
'staff members .is performed. 



The basic role of administrative safeguards is to establish 
those activities which are inunctions of human authorities, judge 
ment and* decision processes. ' ^ 




2.4.2 Physical Security "Administration 
2.4.2.1 Physical Access 

Controlling access to the data processing facility .or its 
individual component resources is a basic step in providing 
^security. It should > however, be* considered as only the first 
level of security and represents the base upon which the 
.other levels/forms of security^build'. The following con- 
siderations are necessary when .creating security procedures to 
restrict personal access. 

o Areas to b.e restricted; may include: 

® - the overall building, 

- data processing cente^Cs), 

' * - tell. ancillary equipment and facilities (key punch, 
ftcey tape, printers, . bursters,, etc. ) , 

- remote job-input or output devices, - 

- remote terminals, it 

' - auxilliary power, fuel or water storage areas, 

- communication cable housing o'r concentrator \ ^ 
locations, etc* 

o Multiple levels of restriction: . A person who haa^a 
valid tieed to access one. area of the data pro- 
cessing facility will not necessarily need access 
to all or other areas of this facility. When pos- 
' sible, access to the ^Jidividual areas \shpuld be 
separated and^controlUd individually .\ 



' Mell^d of access restriction : Choices of haw access 
is restricted may ^include: ^ 

r locked doors (k^y^r combination- operated) , 

guarded Moors (SSdpersonai identification, 
« guarded door's ywith badge or pass iWtifica- 

tion, ^ . 
^ ^ - electtically locked doors ^activated by^ the 

individual using a number code, ; ^ . 

- electrically locked doors activated by 
magnetically lencpded pass or badge, 
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- electrically locked doors' activated upon checking 
personal identification (signature, palm or finger 
print (not readily feasible), or ^ 

- comMnations of two or more of the above. 



When determining an access control method, ^t will also be 
necessary to consider the manner in which these devices will 
function from inside the controlled area — particularly in 
^rergency sit\iations. Devices must permit free and ready exit 
in time of emergency for personnel safety (as required t>y , » 
applicable fire/life safety laws and regulations). 

2.4.2.2 Disaster Protection 

, While the data processing resources shouid be protected 
against the physical damage/loss bf equipment, provision jEjg^ 
continuity qf operations must also.be given priority attention. 
Potential occurences should be ranked by , livelihood, and 
reasoi;iable preventative jneasures should ie instituted.. Some 
of the more likely occurrences are:^ 

6 loss of power, (total or shortage), 

o loss of water (for some ^equipment,- air conditioning), 
o , f \re, , ' ^ ' * 

o flood or water damage (natural, broken piping 
inside or outside facility, or fire activated, 
o explosioi;,' etc. * 

Various methods can be employed to minimize identified 
possibilities. Some alternatives available are:* 

o alternate public powet routing, 

o - private gener*ators (with or without eiectritally 

activated uninterruptable features), . . « , 
o private water storage facility or acquisition 

plans, 

^,0 appropriately X^ted _i ir-e-^tesistant-md^rialsi^ 
.0 proSucts^of combustion or heat activated fire 
* suppression/systems (Halon, sprinklers) , *etc. 



2see also NBS FTPS PUB 31, Guidelines for Automatic Data 
Processing, Physical Security and Risk -Management, (June,.' 
-1974), SD Catalog Number C13. 52:31. • * ^ 
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2.4.2.3 B^ck-up Facility- 



In the event of a total. or significant partial loss of 
the processing capability of the ADP facility, it will be 
necessary to activate either af contingency plan or the 
enlergency"processing plan (see Section 2^.1).' Physical 
security measures must be provided for this back-up faci- 
lity as well as during the movement /of neqessary forms, 
data file^, output, personnel, etc. to/from the back-up 
site. ^ 

2.4. 2 ;4 Storage Libraries 

* <. 
Adequate physical storage areas must be set aside for 
the protection of . • , * 

o tape, disk, card lEiles /records, ^ ' • 

o pr9gram documentation including operator run documenta- 
tion and programmer/analyst design and maintenange docu- 

, , mentation, 

o various administrative security contrqA- records/plans 
including ^ . 

- authorization lists, 

security profile/level documentatipn and, 

- emergency back-up/processin& plans. • . / 

Tl/ese areas must be appropriately structure to preclude 
access A>y unauthorized personnel and also to protect against 
disas^r. These libraries should generaMy receive, the , \ 
highest degree of both access and disaster security. in_ cori- 
4)arison to other*- ADP resources. "Sinte many of the data tiles 
will be back^ui^ at*offjsite locations, the off-rsite facility 
should receive the"' same .or comparable level of security protec- 
tion. Appropriate precautions must be taken during the move- 
ment .of these files between sites.- |« ^ 

' < ." 

2.4.2.5 iJata, Handling and iJlsposal • — , , 

Certain physical security techniques may be appropriat^fe-- 
in the handling of data within the ADP facility. If multiple 
secifrity levels are employed within the facility* hat>dling of 
this information should^be either restricted to tho^^ ^eas 
necessary ^ or methods must be instituted to prei^fnt obs'erva-, 
' tion as the information is moved (such by means tff sealed/ ' 
locked containers /<:arriers/truck's) . 




Ctbnside^ration stiOuld^hfi'giVl^h to readily identifying, 
in some physical manner ,1 daC^^containing restricted or per-' ^ 
sonal information. This! cp^d be done by means of visible 
I'^eling, color . coding of^ labels or reels, phyj^ically sepa- 
rating storage locatio|is of such files, etc. However, it , s 
should also be remembered that such techniques also readily 
identify these files for improper access attempts. 

*. • * 

It is also necessary that appropriate 'disposal techfiiques^ 
be devised for outdated files, input and/or output. When infor- 
mation is no longer retained, the file should be erased or des- 
troyed such es by degausing or use of write-over procedures 
befor^e re-use. Computer generated scrap material suQh as forms 
used when aligning pr-iuters or when jobs are redone should be 
handled £n the same manner as' outdated input and output. Nor- 
mal means of disposal include, shredding, ^incinerating (may prq- 
, duce environmental problems) , compaction or mulch^g under esta- 
blished control procedures^ » 

/2,4.a Technical Security 

o Security System - o 

The security officer' is re'sponsible for the mai^enance . 
of the security system programs and all files associated 
with it. Requests for changes in user profiles must be"' 
^^riginated by^. ar^a management with appropriate » manage- C 

m^^nt .and security .approvals. (Changes to the area security 
^ ^ administrator profiles are made onljj, by the security f 
administrator.) . ''^ * - 

o Data and Files 

The security administrator is responsit>le for the pro- 
' gram to protect the contents apd^phys^tcal safety of all 
files. Using thS security system he -must ensjure^th^t the 
system is' adequate to prpt^feet all data, f ^ 



Program Libraries * o' . * 

The Security, Administrator is responsible *f or, ens^ring^ , 
the accuracy of gxQarajoa/Xibraries* His functions in this 
regard include: 
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- ensuring that fin access control program to restrict 
b access to all programs and any test files under his 

control is' -operational 

- providing copies of programs and appropriate test * 
^data only to authorized personnel upon receipt of } 
written requests from appropriate mani^ement personnel, " 

- providing a method for applying program changes and 
^ ensuring a reasonable period of parallel testing, and 

- providing appropriatie backup facilities fox program, 
libraries and data files t^ ensure continuity of^* 
processing. » . / ' ' • \ 

, ' t 

o Operating Syst^ X * 

Lii^ ADP management is responsible fbr the maintenance of 
^ ,the operating system, and should apply ''fixes" generated 
by hardwar^ vendors with the approval of the system pro- 
grammers; ^nclvded in this' is the responsibility for mainte- 
nance and testing of. changes to the^system. Responsibility, 
for the change of s^curity control security and 'the stability 
of the operating system rests with the Security Admini- 
strator, 

o Telep r o ces s ing 

The security administrator i3 responsible for: 



- user-. tables and teleprocessing, security 

(including the maintenance of security modules 
witb^ the TP system),' and 

' ' . - backup and recovery of TP systems (including 
. " backup features (e*g., dial up), line control 

and investigation of ^security violations) ^ 

9 o Encryption ^ 

The security' administrator is responsible for^ " 



- , maintenance of encryption algorithms wher^ appro- ♦ 
' priate, and ' ^ \ 

- control the generation, distribution and use of keys for . 
use with the algorithm. , , ^ * 
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2.4.4 Training * 

There are two aspects to trainirrgs^for the security function * 

o. training for those who implement, maintain, and operate the 
system, and 
: o trainy^ng for those who use the ^stem. 

The first grouu.-&hauld have a more formal training, curriculum^ 
^toupled with an e^^Tablished career path in ADP security ^addiinis- 
tration. A var^^ty of subjects ranging from technical aspects of 
design and us€of ADP hardware and* software *to the provisions of 
the Privacy yAct should' be talight on a regular basis. 

The user$ -of the system' should be given training on the 
the conseq;uences of a security violatio^^ etc. These users 
should be examined periodically ^to ensure that they are pro- 
perly trained. ' ^^J^ 

5.4.5 A Suggested Security System for an On-lin^System - 
An Example ^ 

The Sjecjirity system desired for large scale on-line systems 

must be .comprehensive enough to* act as an effective buffer between 

the terminals and the application programs and file^. The level 

of sophistication can be reduced as sysj^|a size and complexity 

ar^e reduced. ^ However, some automated* ^s^'tem should exist. The 

suggested system is comprised of three securit^^^f iles ^ 

follows: . * , . . " ' 

. * p J . 

o Terminal file * - 

16 . This file contains all necessary information regarding 
current status of *the terfeiTaal, ingluding: • ^ 

f . - Terminal ^ID - a unique ddenti^er synonymous with 
\ ^^the specific 'terminals 'This identifier's a hardware 
^feature of each terminal and- is contained in every ^ 
message sent' by .the terminal. ^ 
V _ ^User Il!)'±^unique identifier which is inserted in ^ 
* . this fiRafter-a successful log-on. This field^is 

' appended to^the transaction message prior to logging. 
the 'transaction. This assures that each message 
e| . contains Oihe identification of tKe siding terminal,", 

and tHe person sending- the -message. 
Terminal status - this fierd contains the status of 
the terminal!, • ^ * ' 
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— dormant - terminal hag not as yet 16gged on 

— Idg-on in process ^^qg-on message received but 

password not verified * r 
— active - log-on suecessf ully^^completed and user 

ID;field updated 
— vlxJMjl^on - security violation attempt discovered, 
» ' Te^Hfel is logged^off untililjivestigation is com- 

pletea, \ 

- Violation counter - this field "contains- the number of 
unsuccessful ^(invalid) attempts to enter -either 3n 
erroneous password or an erroneous 'transaction type. 
If this counter equals some preset number, say 3, 

the terminal status .|Ls set to "\^olaf ^'on, . ^ 

- Time^,c^ last^t t&r^nsa^ripn - t4jfininali^4oes not 
require log-on for e^ch transaction this field con- 
.tains the 'time of la6't transaction fpr an "idle" 
check, v^If the elaps6d time between loaessages- is* 
greater than a preset idle time^'the terminal 
status is set to dormant 'and a^/dog-on is required 
to r'e-r initialize' the- terminal, \ 

User profile 

Tbi'S- file '-contains information i^^rtaining to a ter- 
minal operator , including: ' . 

- User ID .which, is a uiilque identifier synonymous with 
a specific individual. This field is most componly 
.the employee 'number ^f the tei^nlnal operator, 

- Password which, is a, unique com which is entered by 
the terminal operator .which identifies the terminal 
operator to the syst"em. This data Is' ent^ered by 
the operator in*a 'print inhibjit' mode, * (This 
means the 'password d6es not di^lay on the .germinal. ) 
After validation, the' terminal status is S6t to 
"active," Note t^atf there may be mpre than one level 
of password control. 7^ 

- - Transaction codes aire a set of codes which Identify 

those transactions aa"d applica^tion modure names which 
* ..the terminal operator is cleared to perform; After 
a successful log-9ri,_the security- system examines 
ttiese fields to determine if ^''specific transaction 
cdde is authorized. Upon a, successful match the 
application program .module is called and control > 
passes to the application module, -If a successful.^ 
match is not found -.the violation counter Is incre-,?*^ 
mented hy one and the transaction is rejected. 
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o Transaction file 



In more Complex systems the transa 
in conjunction with the user prof 



Transaction ID 

is 



this file. 
Sub-code is 



It 



a unique code 
entered hy the . 




i'ban. be used 
•i^b^k below: 

^ 

the kpy f 0r 
op'erator. * 



a- field' that can be used 'further to 



restrict access to particular data files, baSed on 
the format, w,ithin th^ file; -If the file is 
broken into smaller 'Urrits this field can indi^te 
which of the units can be accessed by a particular 
te^inal and/or operator. 

Fife: ID is a ffield which contains '£he id'entif ication 
\e master file a^^i the specific functions^which 
)e performed' by specific transaction typea 



of 
may" 

against the file. 



^Audit 



Trails 



W/fc^^rally, audit trails should be employed so that'^^ 
/Security Administration cai? monitor data, and .the system 
'Security f eaturea ixegulat^ data .integrity. They^can 
-be- des^gfaed^to provide: a ^^riety of fetatur^s to meat 
unique requirements, for tb^-level of -security deter^niined , • 
to be appropriate ami^easonable for the perceived threats 
in a partQxular organization or activity. In general, they 
^ should be designed to record who had access to', what data.^ 
, Dependent uppp the l^vel of detail desired,^ they can ] , ^ 
' identify /uch things as' the file, the record oi; even 
the data Element accessed^and what transactions were 
performed^ « ' * - 

The function* of the Securfty System is. to act as a buffer, 
reduce the probability an accidental violation and raise 
the level of expertise heeded to commit a deliberate viola- * 
tion. The sys|:em relies Upon a designated securi'fey officer 
in each area. '^^'AII violations ate lagged to a violations log. 
which must be reviewed by a security officer daily and on 
a special log' for review' by tjie security administrator. This 
officer' should also have an- on-line hard copy terminal which 
notifies him, immediately, of each, particular multiple* violation.^ 
He should theij^be required to visit the terminal identified and 
determine theS' reason fox the violation. The office must reset* 
the terminal ' using his special pSecutity code' to permit t-he termi- 
nal t0 functior^ again. In addition he should be-requflPed to 
submit a repoibt concerning the violation to the individual res- 
ponsible for security administration. ' - • 
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3. AUDITING THE SECURITY ADMINISTRATION FUNCTION 



4 



3.1 Organizational- Requirements 

-The following two organization considerations are neces- 
sary when establishing a program to^ audit the Security Admlnistra 

tion function. 

' ' i ' 

o The Audit function should be independent of the Security / 

Administration funxition, , 
o The Audit function may be distriblited but staff audit . 

members must report either directly to the^ agency head . 

or through the heaxi of audit to the agency head. - 

3.2 The Audit Process ^ ^ ' / ^ - 

The audit of the Security Administration function is 
simply a compliance, audit. ^Tfie auditor's task, is to ensure' 
that the statedL^policies are being followed and independently 
to report his opinion* ^ ^ 

The auditor may. find -varying standards and procedures 
within the organization due tQ, dif feirences in size, 'processing 
environment, delegation of responsibilities, ^etc. Because. of 
this,, the auditor must construdt or align/,^xtract an audit - • 
program which is appropriate for •^accomplishing the coi;responding 
Security Administration function. At all devels, the audit 
program should accomplish the following, independently of the^ 
Security Administration function. ^ ' 

o The auditor should appraise the policies and standards 
initiated in establishing the Security Administration 
function. The poli^cies and standards should ,be: • * 



- comprehensive, ' . ' . J - 

- documented, 

- known and understood, and ^ ' , 

♦ Compiled with. ■ . , 

6 The audit pro^ajn should evaluate the degree of compliance 
witK established control procefiures/ and review an^ appraise 
new procedures being contemplated Uiping, generally accepted 

* auditing, standards and techniques. * 

a . The auditor should independently verify other key coiVtrol 
points/pracedures within the Security Administration func- 
tion.^ . ^ ■ ' ' 

o The auditor should identify any need fo^ added controls 
.which^would make the. Security Administration function 
more effective. | ■ ' 



0 The^ auditor must report findings, and opinions to designated 
management. ^ / , 

The specific procedures and, controls to be reviewed by 
Auditing will result from (procedures adopted such as those 
's.uggested by Section 1.0 and the. specific delegation of res- 
ponsibility. " - I i 

^ '\ , ft, ' ^ ' 
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SOME FEATURES OF JQi&HFEDEgAL GERMAN PRIVACY LAW ' 

^ I, PUBLIC, SECTOR DATA SECURITYj ADMINISTRATION- 

'S^ ORGi^IZATldN . * ' \' ^ ^ * ' * 

* !•! The OfficeJet ithe FederaOr Agent ' . °- , 

,A Federal ^agent must be appointied for the safeguarding of* 
data. The agfent* ^ ^ • * ' * . ^ 

^o** ha| a'tienn of- of fice of |ive years,' ^ ^ 

o is^an Independent of f ice* reporting to highest level of ' 

government*, installed ait the off-ice. of the Federal.' 
. , Minister o^.,the Ijijteridr and under, his \service super-* - 
. visory autiiofity, ' ^ ' ' ' ' « * . 

o' has staff ^nd suppart,*and ' 
o has his legal status precisely def injed. 



l,2.\DjiltieS'^>i2f^he Federal Agen^- 

The' duties' of the Federal Ag^rit include 

\o^ verifying compliaitce^ with law>,. * - - ' 
o-- making- recbmmehdatioits-, ~ ' ' , ^ - ^ v ^ 

o issuirig reports, " ^ - ^ , ; ' " 

o *requesting/deriknd'Jng aid- ir6m other agencies,, * " ' ' 
6,. having 24 .hour register of*.da.» banks storing personal ' 

data (public record},^ and ^ - "^^^ ' 
o^ processihg/'hearing'^appeals, ■ * - \' ' ' ' " 

2, PRIVATE SECfOfe.DATA skCURITY^ADMIN^STRATION 

. " ,^ • ... 

2,1 Requirements for Corporater/Asgociation Data .Security Ag.ents 

" * c 

i. ♦ ^ ' . ^ — - . ' - 

• A data security agent, must .be; ^^ppointid by «ny per-son/<s5r-- 

porat ion/association "who processes personal data automatically 
arid thereby as a rule empioys%t least five pj^raona on a. per- 
manent basis," * , . * ^ ' . * ^ 
* ^ • ' ' ' 
\ 0 Requirements 'far ^ the agent include: J y .* ' 

o * must be appointed in^wrij:£ng, 



} 
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*o mufet be competent- to fulfill his duties, 
o may not be put to disadvantage ^because of accomplishiiig 

his duties, ^ ' v • ' - 

o is not s^ubject to outside direction, 'and ^ ^ 

o may aMaoint'/ employ supporting staff. " ' \ ^• 

1.2 Duties of the Corpprate/Association Data Security Agent 

.Duties of the D^ta Security Agent include: » 

o assuring' compliance with the law, 

.0 seeking assifetanee of governmental supervisory; 

authorities when needed and without need for " ' 

' corporati/business^ 'approval , * *^ 

o keeping records on the 

nature\of stored data, 
- its purpose, ' ^ 
' • - persons requi^ng acbess, and 

the -nature of the ADP equipment in use, 

o supetvising "proper" application of -the* pirogr^ms processing 
. ^ .personal iata, • . ' 

* o. training of other employees as, to thMr responsibilities v 
under* the law,^ and / ' - * 

o* acting as ^a con&6*ltant to persons processing personal data, 

3- CONTROLS REQUIRED TO SAFEfiUAilD DATA V , 



Controls specifically r.^qn^ire^d by the law include; ^ 
' • ^ 

o Ac cess ControT^ ^- 

' • / . - , ' 

- "prohibrt^utxaufhorized acce-ss to. the .installation 
/ ' .,;iequipment), and . ' * ' ^ 

' \;y^*r^ifijlit actess to data, to those having ^a^ need to know t 

• -i' ''./^ - ^ * ^ , 

o. Storage Coxrt^rol ' ' ; • - 

prohibit . • - f 

- unauthorized inaput to storage, '"^^rr" • ' \ 

- acquisition of^ ddta from storage * ^ e 
" alteration/cancellatian of store.i data . ! 



o Use Control 



- prevent use of *the data system- by unauthorized 
persons (includes remote access i^se control) 



o Transmittal Control 



- gjuarante^ that oniiy authotized'recipietits ,may be 
sent'*personal information 'Via^ automated installa- . 
tions (authentication) * 

o ^ Input Control - *^ / 

* Maintain the capability to ascertain 

^ ■ ''^ , ' , 

what personal data, ' - ^ " ' 

- at what time, and ^\ ' ^ ^ 
* - by whom was* entered in the system, ' ' . * 

0'* guRerv^sory dontrbl ^ \ , . 

"* ' , ^ ' ' , ^ 

- ' Supervision of instruction: authorization to /process 

personal data * ^' * , 
' - Supervision* of tr^smisslonf of personal data so\ . 
that' it cannot 'be ' ''7 

< I --raltered,' or \ • 

— cancelled without supervision 

- .Supervision 6f the organization/internal structures 

/ • or boards of the company "to assure that data, is p^To- 
perly safeguarded, ' 
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- -- - - - - - 

^The charge giveri to this session was: ^ 



o ^UDIT COt^SIDERATIONS IN VARIOUS SYSTEM ENVIRONMENTS : W^rat are the 
•\ considerations to given to the afldit of computer^curity in - 

various system environments,' suth as (a) distributed^ocessing, 
1 (b) dedicated systems, ..(c) time-sharing, .(d) mul ti-p.roe^ssing, 
(e) mini/micro computers, etc! , 

i - ' ' ^ * - . ' . 

Computer security is generrally ^considered a function ct)f the ^nv^ronment 

in.which the system operates. A dedicated system opera tij^in a batch 
\ mode withi-n a benign envy|)nm^nt has altogether di^-ereftt security re- 

4 .qunrements from a ^sharer automatic resource balancing computer network. 

^ * \ 

' This^ session will address the various system env1ronme,nts and identify 
; ^ th€ major aspects-of each -that the auditor must cons.ider tn aofiducting 
an evaluation of. computer security, • ' ^ " * 



The consensus report that follows was developed, written and reviewed 
by the entire membership of this session, \ . w « 

: ^ ■ ' • ' 6^2 „. , ^ % 
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1. INTRODUCTION ' ' 



'During the two months preceding the Workshop, working papers and 
^- ^ position statements were solicited and received. Relevant literature 
'references were collected and^ disseminated. This documentation was 
j^eviewed with the members of the team during the first wo4:king session 
on T^yesd^y niQrning,y22 March. The team^also began to develop an in- ^ 
'depth interpretation of its charge through unstructured and far- ranging 
;» discussion. . ' 

..^A structured,* top-down approach J:o th^ problem was^ initiated 
toward the end of our first working -day'and work continued along this 
course during the second working session' on Wednesday, 23 March. *^ It 
\ culnjinrfted in four identifiable conceptual modules which are funda- 
mental t6 the developmpnt of an- open-ended, structured model of a 
computer securi^ auciit: • , ^ • 

] *' ,\ ,1 (i )'^efinition<of three vital audit components! e.g., 

> access contrbl, accuracy, avail<ibili^. - - *' 



(.ii) Morphology jOf system^ and environments. Physical 

Qtmponents, systems structure, ^and people -| with* ^ . ' 

rive identifiable systems characteris^ticsTNumber , — . 

of users, types of service, system\ organization, ' ^ ; • > 

user access, and. application mix. \ . ' 
^ J.' ' ' . / . • I ' 1 ' ' ' - » . ' 

(ij't) MethodoTogy, or j:he cc^puter Sudit mo^leT, which*., < . * 

es^tablishes a^scprecard value for iach anti \every' ^, ^ - , 

; paro^netric^l ly, identified control .capable of ^ " ^ . 
being ^udited^. * - " ' . • 

•(iv| Modal • val idation through simulation, verifying ^ 
empirically ,thVough four* examples the " power ef*^ 
' the model .as well its completeness. ^ ' * 

\An overview of our findings Js/presente^c^ln this report: ^The ' 
ChaftTlan ta1<es great pleasure in'^acknowledgTng the ded.idated assistance 
of 'cm team members* toward achievir^ our final g^)al. 'Jheir inrcisiVe 
th'inking, capabi-lity Of» abstraction, and expressive Writing produced 
.the taw material for this paper. The Chairman is especially grateful 
to Mrs. Sheila Brand for her continued monitqrtng of the development * ; 
of, this report in addition >to b.eing a jnember of our- team. However, 
he alone takes full responsibility for any errors of ofnissioli ojr com- 
mission Wfcw<Ti may have occurred during this pditorial process- ^ 

* • • • ' • 2/ -.DEFINITIONS . . 

4 , ^ " 

The principal terms relating to computer systems security^ used 
in .this r^epQrt-trre defined as follows:. 
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Environment - the physical /acilities, s-ystems arch-i tecture, ^ 
^ ^an3- administrative function^ which constitute, .an ADP system to be 
^ audited. * ^ - 'X ^ 

Security Audit - An assessment 'oT the ^system of controls* that 
ensure -the continuity and integrity of t1ie environment as, defined 
by mana^ment. An assessment of the reasonableness of these control^ 
is achieved by examirjing and ev'aluating' control^ over system access, 
^accuracy, and availability, ' > . 

\ystem Access^ - The ability and the means, necessary to acquire, 
store. Or retrieve^data'; 'to communicate with or make us6 of any 
-resource of an ADP system. 

System accuracy - The state 'that ex-ists when there is coijiplete ^ 
assurance that under all postulated conditions* an ADP system implies 
•(-i) total ^lo'gical correctness /nd rfeliabil.ity of Jii£,,«f^'6m, and^ ' ^ 
' (ii)* logical correctness. and dompleteness of the hardware -and soft- 
. ,wape;necessary to implement protection mechan}isms' and to'- assure data 
^ integrity. ^ ' * ^ y ' . ' 

System Availability - The level or'quality bf service^as de- 
. fined by the users, feqcfired.to perform their primary functions. 

• ■ . - ■ 3'. METHODOLOGY ^, . \ 

"3.1 /Audit Ve>sus 'Di5Si'9n • ; • • • 

' ■ ^ .„ . > - ' . . 

- • Th^, process of performing ^security aCidit is closely related to 
•" the security determination study performed during the'initiaT devel- 
opment stages of a system whicb' is to be secured. This conclus-ion _ 
was reached^ as we attempted td'tJ^velop a methodology which is based 
oh an ehumefatiory.of all consfdektion^ applying to theiaudit of 
compter security Hh varioLfs- sye/em eji^Jironments'. We' determined that 
s'pecif'ic^'Compu-ter)re^ated,>p1iysical- and. administrative 6nvinonme''ntal - 
' descriptors requiX^d^clQse iicaminationf They are all interrelated 
V and not readi ly slpa^atsd. J Ou'r;\end- resul t was^the enuitieration-of 
.thos-e steps tO tak^n'Wst/^ the design team and then with- 
> slight variations by tb^'ayftors. ,Jh4s result shouVd.not prove to'c 

^ .4. surprising if One examinf^V'trie composition of an effkt^ye desigrf 
' ■ team. To. build cost- ju'sJWable, .comprehensive a^^d ^^fective se- 
curity "in t'o-^a sys'tem at'^lfest one member of fhat^team should have 
^the^audl'tor's; viewpoint dm hopefujl ly -fee, in f»ct, qual ifij^d>- 
■ ■ auditor. " Thus we see a .twb-prong^d role to be played by the^audft 
•profession. First, the auditor mu'&t be cin .advisor to the design 
I team providing essential '-iijputs *to the molding of the sysfenu 

. s,econd,. during the I'atef/ opferationa-1 phase of the system trfe-^auditor 

must perform the traditional EDP audi t^6r , functions and reassess the 
/• , effectiveness of .the conipute,r system ^ecilffity design. v.' ' "■. / 

- ^ . L . I ' 6-4' ^ ' ' \ - 
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Below, we list the step? necessary to arrive at an assessment of 
system security effectiveness, first for the design team and then for 
the audjt team. " ^ . , ^ 



3.2 Steps the Design- Team,must talcer ' " * ^ ' 

' * * ^ *»• 

'Step (1) ^ DEFINE overall system requirenients, cffjecti\yes»^and 
sensi tiyi^ty. - * « * • ^ -^^^ 

Step' (2) SPECIFY the desired environment, based on results of 

^5 - ^ ^. 0 Specif ication^'Of* phy^ical parameter^ such* as: " 

> ' ; ^ Location of system , " ' 

Construction of ^"contaJner" (building) v^' 
% - Survivability of .system.fundef disastrous'^^ _ ^ ^ 

cofiditions such as floc^d, fire, bombing, e|c^ ^ i/) 

0 Specification of SYsWm parameters such-asr vf - 

* - Degree of information sj^aring (wi l/T. ^here/be 

one or multiple users) 

- Batch or interactrve processing ^ ' 

- - Centra7izea~or'dTstn1)uted data bases, processes 9^ 

, ' (t^ Local or remote access * . ^ ' . 

- AppliGation mix ' , . " rr- 



Specif i(^ation"of admi n i s tra ti ve pa rameters such as: 

- Threat analysis ^ , ^ ' * . 

- Persqrtnel procedures ' . ^ . 

- Organizational structure . • 

- Secur^ity' requirements far:" ' i' 
{3) Access Control 

(b) Accuracy - ^' * ^ 

(c) Availabil ity 

- Insurance . • . if.- 
^ - System, development procedures- 

, ^ f' 

Step (-3) SPECrrT ^ontrolr tectiQiques that can be used to enforce 
the environment as defjined ip Step (2).. 

• ■ • / ^ , ^ 

At this point, it may be helpful to point out the djffer- / 
^nce? between security objectives, poVicy and procedures The 
objectives of the imposed controls, iQ ati o'Perational environ- 
ment are regulation of access', acceiracy afd livailabi 1 i tyf' The 
translation of the (Objective of ^access Control into policy may 
talje^ the form of personal accountabil ity for -all 'sensitive . , 
transactions. The translation of this policy into a, procedure 



may take the form of logging into the system by way of a 
password, or manual hogging into or out of a secure area. 

''Step (4) PERFORM a line-by-/ine cost/protection analysis. This 
is by far the mos^ crucial, step in^building a set of 
controls'to protect the system within its environment. 
In this step we analyze each control line iteo) speci- 
fied in Step f3) Which cbuTd be employed to protect^ 
some aspect(s) of the system. The detailed cost/pro- 
'tection matrix. wi4-Hiave hundreds or thousands of 
1i k'e^tem§ , ' dependent -on the complexity of th^ system^ 

^ For each control requirement four judgments are made: 

\(a) Cost of im^plementatioQ, develt^pmeht and^^ 
operation of coptroL. ' ' ^ 

' ' (b) Eff>t ivenps^ in regard to maintaining 

access control, . ' • . : ^ 

(c) EffeDti veness in regard to maintaining . 
accuracy/ * * ' 

(d) ^*Effectivenes3 in regard to maintaining 

system availability. . ^ ' 

The effectiveness judgments for (b)^ (c), and (d) are - 
' finally trernslated into (subjective) numeric values on scale 
from 0 to TO,^0=rion-effective, lQ=super-effectfv^^ Thls**coh- ^ 
forms to the current state-of-the-art* ^However, a very desirabTe~ 
goal would be to devise instead an objective scale^ of measures 
Of' effectiveness.' ^ . - 



For purposes. of £X)hvehie'nce, the designer may use a short-, 
hand method of rating: , .1 

RATING = AC/A/AV ^ ' . • 

► where: AC = numeric v^lue assi«gn.ed-to effectiveness 
• ^ level of Access Control 

/ * A = num^^ric value assigned, to effectiveness 

'level of Accuracy > ^ ^ 

» .4 * AV = numeric value assigned to effectiveness 
^ * ^0 ' . lev^el of Availability 

' ^" These ratings become part pf the system .documentation an,d 
are us^d io Step (5)^and by auditors. * 




^tep (5) PERFORM Composite ^valuation. After performing the 
--v . ; line-by-line analysis described in. Step (4) a-'specific 
'\ subset of the^^e controls is'selected' as thd basjs for * 
' *the comprehensive set of safeg.ucirrfs . ^Management mu5t • 
concur tfiat this subset provides the necessary depth/ 
.J bread-th -kiid ov^lap of protection most cost-effectively 

for a^l aspects of the environment physical, systems, 
' ^ and adminflstrati ve. In^ other words, this^is- the s,tage 
- ' '.at.wh'ich tKe ''ns|: assessm^t'* is made and a "srecurity" 
■ * system is designed to meet^^the-s'ec^ri ty objectives de- 

fined earlier/' * , ^ / / ' 

Step (6) INCORPORATE the .ai)proved s^urity cortWls. REASSESS ' ' 
this new TOTAL envijfonment* i n light of the additional 
featyres inserted into the three environmental (physi- 
cal, system, and administrative) parameters. •If'^these 
addations^do *not- qegrad? the overall system effectiy^- 
ness (meeting reqyfrements an^ objectives, sfet down 
, in Step ^(1) ),* the desi-gners are ready ta begin im-. 

. • pigmentation, Ho|/ever, if after analyzing' the total 
new system, *it iS Afound that the objectives are no 
- - longer effectively attainable^ an iterative process 

J must be ini tiated^a^d the des'j^ners go back to' 

* ' . ^Step (2), remolding the specifications of .environtnent, 
' v\^r'^ etc., until all recfuirements»'set out in Step (1) are 
effectively satisfied. ^ ^ 

3.3 Steps the'Operational' Auditor jiiust tak^^ . i * . ^ ' 

. , Once the system has be'en designed and illjpl emented, it can 'go, *^ 
into operation. The auditor is now calle;i ufion to assess effective- 
ness of security controls, in an toperation,3l niode.. As mentioned 
earlier, the steps of the initial design .leam and those Of the^ ofierV 
ational au^Bi^r are very similar.^ In "some steps onJy the verb need 
be changed. For example, in Stefi (Ij* the designer DEFINES systems' 
requireinents while the auditor REVIEWS 'the stated reqo'irements as, 
,set down^by managem^t. .J • A ^ . , . 

Step (1) REVjw objectives', requirements and sepsitivi tyliSs 

docLWited .by^managjeraent fdr 'the*systfem under audit! " 

Step (2) DETERMINE the'natjare of the environment- prevail ing 
during. .actual system operation, .independent' of the' 
organizational descriptiorjs. The au'ditor^s percept 
tions of the i^hysi^ajvsystems, dn*ia admihis'tf^^jve 
\ , setup may, be qqtte different from those th^it^ 
' s • specified during the design stage. 

Step (3) IDENTIFY Control Techniques used to 'control the en- 
* , vironment^-as perceived by the auditor in Step (2). 




■ . • , . . . ' ■ 

Here we see' a clear divergence from the design ap- 
. -preach.. Inhere the designer may Have identified a 
^ large^. number of pStential controls the auditor is 
confined to examining only that subset of controls 
' ""^ic" are actual ly.implemeated. Thfe auVi tor"-mak^s-^fl 

: independent examination and may, or may -not, use sys- 

. ■ tems documentation as a starting point for his/her 

rdentificatio^i of the System's_ security components. 

step (4) PERFORM line-by-line cos^yp?^ection analysis.* As'iri 
Step (3), th^e auditor^'R^ot concerned with all possi- 
ble safeguard.s, but onl/with those implemented and - 
properly functioning within the system, as determined 
by his audit. IHiile tKe designer may have given 
1 • * .values to thQ components of the AC/A/AV ratings on>ar\ 
. intuitive, non-objective basis, the auditor will' aug- 
ment these judgmental determinations through- hardware, 
so-ftware, arid other saphisticated (where available) ^ 
. . techniques to. test the effectiveness of each com- ( 

ponent of the rating for meeting the stated security V 
objectives . 

Step (5) ^ PERFORM a Composite Evaluation. The auditor now 
, assesses the total effectiveness of the security 
system, to determine whether it meets the objectives 
set by Management. A comparison c^n thus be made of 
^1?^ designer^ rating and that" found by the auditor 
Since the measures used by designer and a-uditor are 
perhaps _di,fferent, this will be only a qualitative,- • 
- albeit inst^ive, comparison. 

. Step (6) PREPARE report of audit findings including recomnen- 
dations for upgrading security where weaknesses are 
. ^ ■''ound, : e.g., where tlie rating of the designer exceeds 
that determined through audit. It is alsa incumbent 
• up6n the auditor to recomnend changes in overall se- 

curity control requirements if the environment has 
changed from that a^ssunfed during the initial design 
or since an earlier audit. » . - ■ . 

•./■-' 

- 4.- ENVIRONMENT AND -CONTTOL • 

- / -9 . . ■ 

The key, e^em^nt ,,of any^ systematic audit approach is a close " " 
link between the design and tfie audit processes, while maintaining 
a separation of duties between designer and auditor. Care must be 
taken to insure that t-he same factors which influenced the design 
process are well understood and given appropriate consideration in 
tne audit process. Two major factors must be' considered: .the first 



i Si the environment in which the system is to opepate, "and the' second 
is the control- techniques to be employed to enforce that environment. ' 
. It is essential that the design process defines the environment in . ' 
which the system is "to operate and that the. audit- uses that same en- 
vironmental description as guide. If the operational environment 
has changed from that, postulated at design time in a manhe/^pacting 
security aspects of the system, this impact must be' analyzed and the. 
s*ecurtty control .requirements must be reassessed as a part of the 
audit process' in a similar fashion to the procedure initially used by 
the design team. / ^ ' ■ 

The approach being advocated here employs two rather sophisticated' 
checklists ^nd supporting material. The first ' checklist is used to 
establish, in considerable detail, the environment in which a system 
is to operate. In the case of a nfiw system design, this is the list 
of desired system characteristics. In 'the case of an existing system 
'under evaluati.0D:i>,this is the list of already existing system charac- 
teristics. ^W^jciiate that the process described in the previous' chapter 
will work with" either new systems, ^ing des.igned or existing systems 
being enhanced or+C^firely. being audTTted. In the audit process the 
.statement' of the et\v"ironment is givdw."? The auditor is encouraged to' 
p^nt out obvious ih^nsistencies in,i€he environment; if he observes 
any, but the enviroiiniflh^tal checkl ist'is his reference point from 
which he evaluates whether the control techniques specified by the 
designer are , sufficient to en'forc.e the given environm&pt-. 
> • . •' . « 

The second checklist is'.a discrjp.tion of the generic classes of ' 
control techniques which the designer may employ to enforce the en- 
vironment in which his System'*must operate.. As Will be'seen later ,- 
_ these range from physical locks and fences, through internal hardware 
r and software access control checks, to administrative" procedures-. 
During the design process, after the system environment is established,' 
the designer selects .those measures from the control techniques check- 
. list which, he wishes to uti-lize to protect his system. Each of the ' ' 
entries in the control te'cfwif^ue^ checklist represents a segment.of a * 
continuum. Each i tem contains- a range of measure-s. wi th two related - 
variables: the degree of protection, afforded and the cost." At the 
low range 1 ittle, protection is achieved and usually cost is minimal; 
at the high range, a great deal of protection is achieved and the'cos^ 
ilfey be proportionately h.igh. In the example of physical locks on ' 
doors the ran,ge might be from a simple padlock through a sophisticated - 
electronically controlled and centrally monitored door locking system, \ 
with. proportionate cost ranges. "Given the sensitivity of the infor- 
mation contained in the system (from th,e environment statement) tixe 
designer must select those control techniques he wishes to employ and 
the.-appropriate position on 'the protection/cost scale for each chosen 
technique to prov'ide jn the composite the "necessary measure of se- 
curity control. • . 

From a -security viewpoint, there are three basic criteria in de- 
termining the environment #nd in evaluatihg the. suitability of 



control techniques to enforce that ehvironment: access control; accur- 
acy, and aval liability, Eachjof these faofors must/be addfressed in the 
enviro^/nental "assessmeAt, aad^eacji of the contro/ techniques being 
applied must be rated^against all three factor^ Some control - tech- 
niques will no't apply *to certain of these measures; for example locks 
^do not affect the accuracy" of ' the information'but they have a signifi- 
cant effect on access control and on av^ailabil i ty of the system. In 
the environmental statement *the degree of protection needed in each of - 
these areas must.be stated and In the overall evaluation of the control 
techniques a rating. by the designerand the auditor of each of these 
measures must be calculated and compared against the environmental re- 
quirements\ ^ - ' ^ 

Many of the 'entries in' the dontrol techniques checklist are com- " 
plementary^ If one measure is taken another measure is perhaps not 
required. Investment made' in one control technique will determine the . 
. exterj^t of the jnvestmerit needed in. a corpplementa^y technique. The 
relationship between entries in the control' techniques checklist is 
complex. To iVisure that sufficient , measures have b,een taken to com-' 
pletely but' rxo.t /overly enforce the envfronment, the interactive rela- 
tionship of controls within various environments must be explained in 
a guidelines book whic.h should accompafry the checklist /see 'section 5)^ 
The guidelines book will describe relative levels^of effectiveness aiid 
cost of the various control, techniques and wiM provide relative as- - 
sessments- of feasible tradeoffs. . - - 

if 

The designer establishes both the' envil'^onment in which the system 
is to operate and the appro^iriate control techivi-qtie^, The process 
employed 'by the auditor in determining if sufficient cohtrol techniques 
have been applied js qafte similar; The designer scans' the control 
techniques^checklist line-by-1 ine, .selecting appropriate itfemj to be 
employed.^ Then he evaluates the achieved overaM. security^ of the 
system fJith an overall performance analysis determined by logically 
aggregating the selected "effectiveness' measures assigned to the line- 
by-line entries. If this overall analysis does nq,t .provide sufficient 
protection, or if.it exceeds the constraining cost factors, then he 
reevaluates thfe cbntrol techniques or perhaps the environment itself, 
making such chants as necessary to achieve the security needed at a 
sj^itable cost: , . , ' 

The auditor, given the /environment checklist, determines first- 
that the actual operational environment is that "assumed during the' s. 
design stage. He then determines the control techniques ^which \fe be- 
lieves appropriate to achi^eve this environment. He compares his con- 
,trol techniques checkl ist wi th tha'f of the. designer and weighs the 
differences so. as to have a reference against vyhich to perform his 
detailed analysis,. He performs a line-'by-lin^' evaluation of the entries 
in the checklist and then an overall arfialysis similar to that done by 
the designer. Having Completed the overall analysis he may go back 
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and adjust -ms^ assessment of the^ individual! control techniques based 
on a- more complete un/erst^nding of the tofal system. The result of 
this audit process is an overall rating 6f ''how close tji^ design' comes ' 
to -enforcing the security requirements of the operational environment. 
If this audit process pYodcjces a rating of .^ifff icient protection then 
the System can be approved for-use. If it, fields an insi^ff fcient 
rating then the designer must go back onca 4gain to-,the control tech-, 
niques list or to the environmental checklf'st and make appropriate 
changes to .mure the- necessary security o'f 'the system. " - 

. The critical element" in this^process is- the use of the'same ' 
checklist information by both the designer and the auditor. This 
insures a common base from whi.ch -to di,scuss related matters'. It is 
this; common starting point that is the crucial element »of our me- 

^ J;hodology. The selection of elements" from the control technique- 
checklist and the degree of prptfection afforded each element-are 

.o\ften subjective and the designer ^ay wish to >take issue-with the 
au^tor over specific ratings the auditor .haL^iven for some of 
thelse measures. The crucial point is that all elements of the de- 
signWe understood by both -th^ designer and the auditor in a conmon 
conte^. This -complete and 'comnon 1 isting jof measures used by both- 
the designer and auditor is an element that has been lacking in " ' 
previous audits. ; ■ . ' . /? 

.'4.1 Chec-klists * • . - 

Both the environmental and control tkhniques checklists are di- 
vided .into three ^ui3-categon>s': Physical,- system, and. administrative 
In the environ/nental checklist under the physical • heading are thosi * ' 
elements of the. physical environment which materially aWect security* 
ot the syst^. Included is .tlje geographic location of ,m system^' 
taking into accouht the susceptibility to natural and man-made dis- ' 
asters such as floods and crime, any special power or airf conditioninq<i 
requirements, etc. * . > 

, In" the system environment list are those measures which describe « 
the inteirnal structuring of the system. In particular We find here 
those elements which affect the/requirement to rely on internal hard-, 
ware/software measures to enforce the security, of the system. Under 
administrative measures are include^ such factors as the .'sensitivity ' 
and coRcectness of the information contained in the system, postu- 
lated threats to the system; etc. . ' • ^ ■ Vr. 

< ^ ■ ■ , 

Jhe system environment comprises five physical andlogtcal com- 
ponents or main categori^^: ' . • t 

1. Degree pf Scaring: Single vs. multiple user(s).* > ' \" 

2. Type of. Service: Batch vs'.' Interactive ' ' 
, ,3. Or,ganizatioji: Centralized vs. Distributed • 

' 4. User Access: Local vs. I^emote ', . „ : . 

• 5. Application: Dedicated vs. Multf-purpose' • 
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*Tfie control techniques checklist is comprised of the same three 
categories: physical; system -and administrative. The physical con- 
trols ^include the traditional "put ^he ^y-stem in a vault" measures, 
including perimeter control, hazard 'protection 'and, backup* mechanisms. 
System controls include hardware/software access control techniques, ^ 
program 'integrity measures, audi t trail techniques a(\d failure re- 
sponse procedures, Admiriistrative control techniques include what 
are coiimonly referred td as Change Control Procedures,. Each of the 
control techniques must'. ba^evaluated against each of the access con- 
trol, accuracy, arid .avail^feilj'ty -factors, and an overall score must be 
arrived at for each of tfose factors,, ^ ' 

4.2 Guideline Book . ^ t * 

' A crit^'cal element in the methodology described here.is the 
background material which supports the checklist. This guideline 
w^ll be composed of two sections, .The first has a 11ne-by-lihe des- 
cription of the elements of the environmental and the control tech- 
niques checklists; in the latter case the range of protection cost 
of each of the entries is gtven. The environmental checklist must, 
be cross-referenced* agatnst the control techniques checklist so as to 
insure that, if a particular element of the environment is specified, 
some range *of control techniq'ues 'can be applied, * 

Another element of th,e guideline book must deal with the inter- 
relationship between control techniques. From it both, the designer 
and the auditor must be able to determine that If a certain control - 
technique is employed, this may very well negate the aeed for another 
control technique. An obvious \exajnple is that If sufficient physical 
control measures are taken and if all personnel associated with the 
system have equal access to^ the information on the system then re- 
liance on intferrial software access control techniques may be sig- 
nificantly relaxed. This evaluation guideline Is highly sensitive 
to the state of techn6logy cind will need to be updated frequently. 
Specifically, the relationship between cost ^d effecti v%ness of a 
particular form ot protection will- need to be revised frequently, 
and new techniques will have ^ to' be introduced as they are developed 
and become viable, . ■ ' - 

* This overall methodology is a systematic approach to the problem 
of auditing a computer security installation. The approach is sys- 
tematic since the designer arid the'audltor as well worR from a com- • 
pleteOist of both ^the environment In v^hkh the system ris to operate 
and the control techniques which are to be employed to enforce that 
environment. By working from common lists, the designer and th^/ 
auditor can more readily comnunicate differences in their evaluation 
and reconcij^ their evaluations ^ ' 

A number of such checkl ists'are already in existence^ they can 
be used- to form the bas.is of ph6 environment and control t(5chnique§ 



checklists. The^establishmept of a complete and-accijme guidebook 
givrhg both the line-by-line descriptions 'and the element interrela- 
tionships IS a crucial element of this o vera 1 1. methodology yef to be 
accomplished.; For example, see; ' Data 'Processing Security Evaluation 
Guid,elinQS.; Peat, Marv^ick, and Mitchell & C-o., Certieied Publ.1c*Ac- • 
countants; 345 P^rk Avenue, Wew York m 10022.' 

' " • * V 5. GUIDELINES ' ^ ' ' • 

> 

In section 3-we discussed audit methodology and the sequence of 
steps whidh an auditor will follqv/, preparatory to executing his autijt 
function addressed here, TherefSr'e, the purpose of this section is ■ 
to discuss thos-e considerations' which comprise the "ideal" against 
wh.ich the auditor compares and measures data security in various sys- 
tem environments. ' • . 

J', The 'Jideals" are derived from\several".sources , including: (1) In- 
formation and experience which the audit^pr Brings to his- task, and' 
A2) Information, and observations" gatheifed by the auditor in his effort 
to more fully understand the systeip to be 'audited* - 

, • In this s*ection we will not attempt to create an actual book on ^ 
audit guide-lines. Several s^ch reference materials exist already 
Furthermore, ^.the 'brief tim4<available. for this 'wprkshop precl udes 'any- 
such (exh^a|ttv€) effort. ■ However, as sljown .in the gharts Appearing 
the Apjencjix, we . h^- attempted to I'dentify significant categories 
of contm technique£r,/as well as -(in selected instances) some more " 
specific .secur-ity meQsujpes. While the various options within the - 
control technique categories can be expanded upon" by 'utilizing ma- ' 
t6rria]s cont^fned.-.jn reference works (and from the auditor's own ' 
knowledge and e,xperi.enc'e) ^.e have chpsen categories of cont>*ol' tech- ' 
niques. which reflect major security options (in a geneiyal sense) that 
also provide an opportunity for analysis of. the differences among 
selected system environment e-xa/nples.' 

• Our discussions indicated clearly that there are, theoretically 
speaking, many possible system environment^, resulting from a com- 
bination of physical, administrative, and systems des'igp" points of - 
view. -^Iff order to respo.nd to the mandate .given this' group, we chose 
four sample systems which differed significantly from one another 
representing foujh of the most prevalent kinds of systems existent'in 
today's computer/ processing environment. » 

ft* ♦ 

The description of the ^'environment'' for each- of the four sample ' 
systems Is given-in the Appendix; the method by which the constituent- 
elements of an .lenvironmefrt" werp ascertained, was' discussed in sec- 
tion 4 on environment 'and control'. The kinds of control techniques 
wjTch we haye assigned as possible protective measures with respect to 
the^our sample systems were.^briefl-y explained in that same section/ ■ 
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However, our group toolc the further* step of assigning, subjective nu- 
•raerical scale values (ranging from a low, of 0 to a high of 10) to the 

t-hree categorizes of^fiontrol techniques . Our 'choice for these values ' 
'was denved from.th'e group's consensus of whether such control tech- . 

nique^wouTd be important with respect >to the sample system. This . 
'importance" factor wa's considered for e^ch of the thre? basic cate-- 

gories of protection vfhich our definition of "security audit" gave 

their AAA (AC/A/AV) rating: 1. Access control, 2. Accuracy, and'. ^ ^ 
Availability. • . • - ' 

It is;clear t-hat there are certain general audit considerations 
wbich' an auditor will utilize in determining* the Vulnerability of a 
given system. . These are the experience items whfch the auditor naust 
bring with him, to .successfully complete the ass^ig^ned task. . ' 

« . . 

In the Appendix, therefore, we considered only some specific \ 
aspects„ of the four sample systems. We Highlighted those tTiat affect 
security cbnsitierations <in a way that distinguished one system from 
another.. Obviously, in'a complete audit of security, one. would ex- 
pect an. audi tor to perform^^a much more'' Comprehensive analysis. But 
'we assumed that the purpose of the mandate given to our group .was to 
foc'us upon specific problem arerfs in different system environments %o 
whith an auditor should pay particular .attention.. The more general 
case, as the proverbial textbooks explairi, will be left as an exercise 
iJgT the ^reader. \ . ' 



^6. CONCLUSIONS ' ' 

WjlTiam C. Mair, co-aut)ior of Computer Control and> Audit , r^ 
cently observed .that "DP Auditors are not and cannot be policemeff." 
He slated that the primary responsibility of the DP Auditor is to ' 
act as .an a^visbr'to management,, to empftasize the need for, standards 
which must be properly documented and coWiunjcated^. Standards serVe 
as 'the foundation<on which everything else is built: they .provide 
direction, predictability and criteria for evaluation. Through- ^ 
these standards the auditors establish systems controls which in turn 
help reduce adverse effects encountered in a basically hostile en- 
vironment. , In fact,*the auditor is^part of .these controls. 

Areas of vulnerability must be exposed to reduce risks to ac- 
ceptable leye.ls. 'The -dangers confronting EDP'systems include, above.- 
all, erroneous management decisions; but also embezzlement and fraud^ 
loss or destruction of assets, excessive costs and deficient revenues. 
Their impact can be severe, leading to competitive disadvantage, ' ' 
statutory- sapctiojis, even to*economic, political, and military dis- ^ 
•asters; . ^ 

We must not ever Underestimate the^power, ingenuity and perse-^ 
verance of the "eneiny". As we relat^development af controls . to' * 



6-N 



103 



potential* exposures^ we must .follow a rather simple-minded approach: 
if we can think of it, someone else can also. Thus the auditor must 
be ingenious about gathering .basic an'd detailed information; about 
evalQating the system's strengths and weaknesses; and about' testing 
xits design and ^^performance. * He must review aJJ of Tts- components 
ihdividuaily 9nd collectiyely according to a s'tructured model spe-' 
cifically designed for that purpose . . , 

A definitive, open-ende4 jnodel has been develgped to structure 
both the, initial internal (^sign'and the follow-up (external) com- 
puter security audits in vario^js system environmen'ts. The mode.1 is 
predicated on the notion that for a system *o be viable within a 
well-defined «(and definable) environment, we must certainly maintain 
controi- over access- to the system^ must , provide accurate services 
and must assure tha timely availabll ity of these services'to the 
users. • ; ; / 

In making the audit, .we assume the availability of standard 
guidelines for rating all identifiable system line items with re- 
gard to^their contribution tb access control, accuracy, .and 'avail- 
ability. A global measure of7sej:urity audit can thus be,de^^ved « 
from the.^line items' indi vidual,^ lotal ratings, A number of algo- 
rithms hSve been suggested for'' converting the aggregate "local" into 
"globaVI' ratings, but it appears as- if ohly absolute and total com- 
pliance with. the design specification ratings will be acceptable 1h 
the security environment. - , . , , ' ' . 

In summary, we find that people are- the critical\element in all 
c(;)mputer security audits. To attain-perfect security, therefore, 
we^are left^with an obvious choice: Either'we abolish computers ^ 
or we abolish people... \ - ^ ^ 
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•APPENDIX: FOUR EXAMPLES 

To determine the effectiveness- of 'the proposed methodology, four 
•representative types of systems covering various /acdts of the system* 
environment were partially ^analyzed. The results of the analyses .are 
discussed here* . ' , , 



SYSTEM sk'ECTIOH 



■The fourSystem tyiJes s^l ected' reflect- at least. one example' of 
each category in the wide, spectrum of possible system environments: 

^ J]7Si " College -computing center ^ • . 

2 - Airlines reservation system • • j - • 

^3 - Electronic funds transfer $:^stem - ^ ' * . . 

'4 - Welfare check disbursement system . ' • . . 

Tlte objectives/requirements of e^ch system were discussed and 
^pertinent constraints and assumptions were 4fldica ted- As the analy-- 

• 'sis proceeded, further assumption^about the system, t)bjectives or 
constraints were requif^ed for^^^^^tan For example, it was 
assumed that the college computing center was \is^cl strictly for* • 
training purposes and fpr nonsensiti\)^e research, Nc/sensitive infor- 
matics (e,g, grades, payroll, etc) and no critiC^Sippl ications 
(a-g,, class scheduling) would be .placed on the',system. Similarly, 

^ it w^s assumed tha-t the airli.ffes";reservatiDns system had e>:tremely. 

.high availability requirements. but could tolerate errors to some 
"reasonable" extent, The^leatronic funds transfer system was as- ^ 
sumed'to\be a netvyork of individual processors located in separate 
financial institutions, retail outlets, etc; linked via' crypto- , 

-'graphically protected*! ines' to provide for the transfer of funds be- 

^ tween sites as one (j| their functions. The welfare check disburse- 

* ment system was considered typical of large singl ^r^functibn. dedicated 
funds disbursemeint systems much lik^e a» dedicated system to prepare 
corporate payrolls. It was assumed that .inputs arrived on magnetic 
tape and or\e run per .month was made ta prepa^re the ^hecks, 

■ ' • 2. DETERMfNATIOl!|^fevENVIRONMENT' • , -^^ ' ... 

2.1 Physica? • ' '" • ' ' — 

Two factors were selected as typical ofa)hysJcal ehvironmeqtal 
concerns which must be covere(J/'by the atid it, location andiurviv- 
ability requirements of the system, ' ^ , '\, » 

2.2 Systems" ' ■• . ' . \v- ' 

' The systems environment was. the, main focus of this WoMshop.', 



The five systems aspects to be considered are: ' • 
V . , • . ' ■ . 

• Degree of sharing (si.ngl.e or multiple user) 
• -^-^Type of service (batch or fnferactive) 
1 . • System org^m^ation-^central ized of distributed) 

User access (locator remote) ' • ' . 

. -Applications mix (-^^ngle-dedicated or ^multiple) ^ 

As- ijidicated ab(jve, t'he four chosen 'systems together call upon 
»ach system environment aspecli a^t least once. ' - * \ 

2.3 Adminis*trative ' • ' • - 

* » \ 

Two representative areas of administrative environmental factors 
were considered here: the sensitivity. of the system and the postulated 
threats to 4;he -system. , - . ^ 

• . ' ' * ' 

After we se-lecteti the factors for analysts,, the workshop members 
collectively discussed them and determined the corresponding impli- 
ca.tions'far each of the four systems.. Obviof^.ly, i.n ah actual audit, 
many more environmental factors need be corrsidered. Typically, ap- 
propriate elements will be,seJected for ciDnsi deration from an ex- 
'• haustiv^ enumeration of security related facto'rs. . ^' 

■ ' , ' . • 

3. IDENTIFICATION OF CONTROL techniques' - ^ 

After the sample environmental factors had been established for ' 
^each systenj, a representative sample of control techniques was de- 
,veloped by group consensus. • Again,- this work woul^ typically be done ' 
with th.e help of an exhaustive list. Several' techniques for each 
categ&ry (ph)csical, systems, and admihistrative)<were selected for ' 
evaliCation. : * , - • ." ' • 



3.1 Physical 



. Perimeter controls - this would be ^ composite (in t>iis example) 
basefl on both people and "things". Virious "layers"' of 4)erimeter 
•controls would be 'considered (site, buMding,. 'room, w.S.11 thick- 
ness, doors, -locks, enclosure, etc.) a'nd varfbus' aspects/ (ducting, 
• filter, fire protections, air conditioning, T.V. monitof-s, ' / ' 
guard forces, etc.) " \ - . > " 

. ^Backup Site - locations, security, availability, etc, 

. .Disposal controls - control ^ofoutput, 'shredcji-ng, etc. 

. "Communications p'^otection - 1 ink-by-1 ink -encryption, shielded 
.• conduits,- etc. ' • ' • . 
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3,2 Systems . » 

• Internal access controls - hardware/softwa're controU-^or 
iderjtifiMtion/authentication, access authorizatron /enforcement 
djiethods; etc, ' ' - 

. Pragram integrity measures controls- on self-chrecking, correct- 
H ^ nesr,^ reliability, etc. . 

Error d^etection/correction r^-c>jclic redundancy checks*, redundancy, 
monitors, self-testing, etc. 

\ Audit trails- . . • * - ' 

^ ^- Failure, response - sotware and hardware y ' - 

, t Communications.- end-to-end encryption, methods 

3,3- Administrative ' 

. ' Perimeter acfcess procedures ' / » . " ' 

• Maintenan'ce Procedures - spftware and hardware • • / 

. Backup procedures - off line, and on line 

* . • ^ * ***"<«»^ 

' Personnel procedures - training, indoctrination', bonding, etc. ' 

/ Development procedures - standards, configuration management, 
certification, etc; • , * . ^ ^ " i 

^:V ^4. CONTROL ANALYSIS - \ ^ ^ 

'Ooce the sairipl e 'control techniques- \;^re ^umer^hi^d, each s^s'tem 
. Was evaluated on a scal-e from 0 (completely lacking] to 10 Cma^imum) 
against each control-. Three criteria were used for: each evaluation - . 
the relative degree to -which the control in that environment provided' 
protection wfth -respect to: ' " * \ . > 

Access control to system * 
. . Accuracy of.'^ystem . - 

Avail abilitj^^ of system 

All. members of the workshop participated \n the discussion of * 
each iteji. and an overall consensrus was. use,d* to arrive at the results 
shown. ^ ^Sorne*" results reflect dur Impressions of actual systems where- 
as others reflect possible "design objectives". .The fallowing fig^ures 
show the- results of our sample analyses. , , ^^.^^s^.^^ 

* ■ U ^ ^ • • ^ ' ^ • , • ' 



5.; eOMPOSItE EVALUATION 



"^The next Step wopld^be to derive an overall composite rating for' 
the degree to which the system provides .protection with respect to- 
availa^iTity,.accuracy^d access controV, and to compare that with 
the security objectives determffed by the system manager. Th4s,com-" 
parison must' include analyses of trafleoffs between the various^con- 
trols (i:e. good physical controls may perrrtlt relaxed systems con- 
trols or vice versa). Jt must also evaluate the Weakest '1 ink. in' 
the chain." A satisfactory technique for doing this must yet be 
developed. • ' , ^ , . * * ' % 

'One suggested approach wauld-be to prepare parametric "ranges" 
or "maximum" values fdr each control technique line, item- as a tmcA 
tion of a specific system environment under evaluation. These cri-p- 
cal values could then be aggregated by subsystems "to yield critical' 
parameters for their assessment. For example, an\ acceptable critical 
.value for'a subsystem^ mSy be defined. as^the highest* numerical param- 
eter selected from the entire set of parameters which' make up-the 
line items for^ this subsysteln. Conceptually, we ran continue tfijs^ 
process of aggregation hierarchically unti,l all microscopic le>tels* 
of control adequacy' on the (lowest). -1 i-ne item level ^avfi-been^rar^- 
lated into macroscopic' parameters on higher subsystem levels. " It is 
perfectly conceivable, even at this very preliminary stage of the 
investigation, that a "standard!" scale fo> system Security may even- 
tually evolve from the' crude beginnings postulated here. 
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EXAMPLE NO. 1 ' '^ 



general Purpose Multiuser Programming System (e.g.. College Computing Center) 





ENVIRONMENT ^ 


"controls ■ ., 


5 

RATINGS , 


p I 

■h c 

J A . 
S L 


LOCATION: Coll-ege Campus 
_ SURVIVABILITY: Low 


PERIMETER CONTROLS 
BACKUP SITES 
DISPOSAL CONTROLS 
COMMUNICATIONS PROTECTION . 


11-12- 
A / Q / 0 • 
>7 - / - 
0 / - / 0 


S E. 
Y M' 
S S 
T 


DEGREE* .OF SHARING: Multiuser 
TYPE OF SERVICE: Interactive 

■ SYSTEM ORGANIZATION: CentraTTzed 
USER ACCESS: Remote- 
. 'APPLICATIONS MIX: Multiple 

' < 


INTERNAL ACCESS CONTROLS 
PROGRAM INTEGRITY MEASURES 
ERROR DETECTION/CORRECTION 
AUDIT TRAILS . 
FAILURE RESPONSE ' : 
-COMMUNICATIONS PROTEQr[iON. - 


i / - / - 

- / 07 - 
-7 0/- 
0'/ 0 / - 

- / 4 / 4'-' 
0 / - / 0 


A T 

M' A 
.1. T 
N I 

I v., 

S E 


TYPE: Non-sensitive h 
^ THREATS: Denial of Sen 
. Theft of Serv 
Spoof ing ^ 
Lo'caV 


/ice^ 1 
ice 


PERIMETER^ACCESS PROCEDURES 
miNTENANCE ACCESS PROCEDURES 
BACKUP PROCEDURES . 
PERSONNEL PROCEDURES ■ ' 
DEVELOPMENT PROCEDURES . 


2 / - / '2 
2/2/4 
- / / 0 
1/171 
.2V 2 / 4 


, * ^ . 

H&te: ACCESS CONTROL / ACCURACY / AVAILABILITY' • 
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EXAMPLE' NO. .2 ' ^ . • . • 

Dedicated Data Base fla nagemeot System (e.g.. Airline Reservations)- 



ENVIRONMENf 



LOCATION:-- Multiple • 
SURVIVABILITY: High ' • 
SPEQIAL: Dial -In Access 



DEGREE^OF SHARING: Multiuser > 
TYPE OF SERVICE:. Interactive 
SYSTEM ORGANIZATION: Distributed 
USER ACCESS: Remote 
APP^LIGATIONS MIX: Dedicated • 



TYPE: Sensitive 

THREATS: Denial of Ser^ce 

Unauthorized Disclosure 
of Data 

Remote 



CONTROLS 



PERIMETER CONTROLS 
BACKUP SITES 
DISPOSAL CONTROLS - - 
COflf^UNICATIONS PROTECTION 



INTERNAL ACCESS CONTROLS " 
PROGRAM INTEGRITY MEASURE^ 
ERROR-DETECTION/CORRECTION 
AUDIT TRAILS 

FAILURE RESPONSE " * 
COMMUNICATIONS PROTECll'lON 



PERIMETER ACCESS PROCEDURES 
MAIJ^TENANCE ACCESS PROCEDURES 
BACKUP- PROCEDURES 

PERSONNEL PROCEDURES 
DEVELOPMENT. PROCEDURES 



RATINGS 



5 / - A 5 

- / 3 'f7 

4 / - / - 

0 / - / 6 



7 / 
-V 

- / 
1 / 

- / 
0 / 



/ - 
I - 
/ - 

/-8 
/ 0 



4 / T /-4 
6/6/8. 
- I - I 2> 

Z I 8 ./, 5 
4 / 7 / 9 



.Note: ACCESS CONTROL / ACCURACY / AVAILABILITY 
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EXAMPLE NO. 3 



Distributed Multiuser Remote Access (e.g.. EFTS) 





ENVIRONMENT " ' 
=^ . ^ ^ 


CONTROI ^ 


0 AT T MP C 


p I 

H -C 
Y A 
S L 


LOCATION: Multiple 

SURVIVABILITY- High 

SPECIAL: Encrypted Communication 


PERIMETER CONTROLS • 
BACKUP SITES ' 
DISPOSAL CONTROLS 
COr^MUNICATJQNS PROTECTION 


6' 1-11 
t 12 1 S 

s 1 - r- 
1 - 1 1 


".S E 
Y M 
S S 
T 


DEGREE'OF SHARING: Multiuser *^ 
TYPE OF SERVICE: Interactive 
SYSTEM ORGANIZATION: Distributed 
USER ACCESS: Remo.te 
, APPLICATIONS MIX: Multiple 


INTERNAL ACCtSS* CONTROLS 
PROGRAM INTEGRITY«-MEASURES ' 
ERROR DETECTION/CORRECTION 
AUDIT TRAILS 

FAILURE RESPONSE • . - 
COMflUNICATIONS PROTECTION 


9 / - / 5 

- / 8 / - 

- / 8 / - 
8 / 8 / - 
8/8/4 
8 / - / '3 


A T f 
D R 
M A. 
I T . 
N I 
I V 
S _E 

f 


■^'TYPE: Highly Sensitive 
THREATS: Misuse " - 

DeniaJ -of Serrvice ■ 
RemotV 
«. ^ ' 


PERIMETER ACCESS>ROCEDUR£S 
MAINTEflANCE ACCESS PROCEDURES 
BACKUP PROCEDURES 
PERSONNE^L PROCEDURES 
., DEVELOPMENT PROCEDURES • 


S- / - / '8 
8/8/6 
6. 7 3 / 7 ' 
8 /• 9 ■/ 7 ■ 
8/9/7 


* ' • -, • — 

Note: ACQE^S CONTROL / ACCURACY 7 AVAILABILJTY " 
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EXAMPLE NO. 4 

Dedicated Batch - bollar Disbursement (e:q., t-Ml fare System) 





ENVIRONMENT- / ~ 


■ CONTROLS • ' 


* 

RATINGS 


P T 

•H C 
Y A 
S L 


uuuMiiuii. oing/e bite 
SURVlitABILITY:/ Medium 


• PERIMETER CONTROLS 
BACKUP SITES' • • 
DISPOSAL COItTROLS' " 
COMMUNICATIONS PROJECTION 


4 / - / 4 
- / - / 5 
•5 / - / * 

0 / - / b 


S E' 
Y M 

S ' S 
T 


. DEGREE OF SHARIlfe^-^JtTigKUser . 
TYPE OF SERVICE: Batch 
SYSTEM ORGANIZATION: Centralized 
USER ACCESS: Local • 
APPLICATIONS MIX: Single 


/IHIEWiAL ACCESS 'CONTROLS 
■kROGRAMnJTEGRTTY mfa<?iirp<; 

ERROR DETECTION/CORRECTION 
■ AUDIT TRAIUS- A 
FAILURE gESPONSE 1 
COMMUN ICATII^NS ' PROTECpDN 


0 / -/ 

- / R / - 

- / 0 / - 

- / 8 /•- 
0 / 8 / - 
r / 0 / 0 
o:/ - / 0 


A T 
D R 
M A 
I T 

I 

I yf 

s eK 


TYPE: Sensitive , 
•THREATS: Misuse 
Local 


• 


PERIMETER ACchs-PmJCEDURES 
•miNTENANCE ACCESS PROCEDURES 
pACKUP PROCEDURES ^ 
PERSONNEL PROCEDURES"^ 
DEVELOPMENT PROCEDURES 


4 / - / 4 
3 / 5 /. 3 

-;/ - / 5 

/ 3 

■3f/ er / 3 




Note:/ ACCESS CONTROL'/ ACCURACY /-AVAILABILITY 
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PART Vli:' .ADMINISTRATIVE AND PHYSICAL CONTROLS 

* . " Chairpers^on: William Hug\\ Murray ^ 
': - ' / ' IBM Corporation , • 



*Pacticipants: 



W. Gregory McCormack. I r - 
Western-Souther^ Life ^ 
Eldred Nelson - 
'tRW Sy^ems Group • 
Kenneth J ; Orr 

Langsfton, Kitch & Assocfates^ 



Susan K. Reed, Recorder^, 
^ Nation^J^ Bureau^^Of Stapdards 
Barry Wilkins 
IBM Corporation 



J ' 




*From left to right: Kenneth T.. Orr, Susan^K. Reed, Rotprt V: Jacobson 
(visiting session, coordinator) , William Hugh Murray, BaVry Wi.lkins, * 
Eldred Nelson, 1ft. Gregory McCormack II - • 
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^ EDITORS' NOTE ' 

A brief biography of the Session Chairperson follows:' * * - 

Mr: William Hugh Murray is Senior Jt^rketing Support Administrator 
in 'the Data Security,. Support Programs Department of IBM*s Data Process- 
ing Division. He previously managed the develqpment of the security 
suD-system for IBM's* Advanced Administrative System. He is the author 

.of the IBM publication /'Data Security Controls and Procedures^" of- five 
IBM training videotapes on data security, and a contributor to such " 

^ other IBM publications "Considerations of Physical Security in a Com- » 
puter Environment." A frequent speaker on ,data security topics, he has 
appeared on national pfograms of the AICPA, EDP A^iditors Assoc\ INFO 
76, and Data Comm 77.- He has appeared before SH^RE and* GUIDE 'irkthe ' 

. U;S. and the Diebold Research Program' in Europe. In, 1974, he chaNred 

^the Audit Working Group of the NBS/ACM "Workshop on Controlled Acces- 
sibility in Shared j^esource- Computer Systems." He holds a BS in-3usi- 
ness A^ministrat^ion from Louisiana State Univer'sity. 



The charge" given to this session^^^was: ' 

i , AD MINISTRATIVE AND PH^^SICAL CONTROLS : What are the audit approaches 
and techniques for evaluation of administrative and physical con- ' 
trols in an ADP environment, including contingency planning, etc. 

' . ' • . ^ 

^Administrative controls are defined to include both procedural and per- 
sonr\el security 'as follows: Procedural security - The management .con- 
straints, oj^rajional procedures, accountability procedures, and 5up- 
plemer^tal cor^rdJjS estah^lished to provide an. acceptable level crSf protec- 
tion for sensitive data. Personnel security - The procedures establish- 

* ed to insure tmaf^all^l)ersonnel who liave access to any .sensitive infor- 

* mat'ion have th'e r^juirecj^authorities as well'as all appropriate clear- 
. arices.'o,. . ^ r^' • - 



Physical controls include the use of locks, guards, badges, and sfmilar 
administrative measlires to control Bccess^ta the computer, related , ' • 
equipment, amd information media. Further, it includes the measures/ re- 
quired for protection of .the structures housing the computer, relateid 
equipment and their contents from damage by accident, fire, and environ- 
mental hazards, ^ ^ 

This session is to address -the ^udit approaches and techniques for j&val- 
uajiion of administrative and physical controls with. emphasis on those 
a'reas that have not been subjected to extensive coverage in the litera- 
ture. FIPS PUB 31 can be_used bs a departure point* tljis session. 

This is a report of the consen'stis* arrived at by the working group/ 

' * • 
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REPORT OF TH 
ADMINISTRATIVE 
- ' CONSEN 



3 WORKING GROUP ON 
& PHYSICAL CONTROLS 
US REPORT , 



WILLIAM H. MUkRAY, BARRY WILKINS 



1. 



REVIEW OF [the charge 



^^rnr^J^^ invitatioHal worktop on audit and evaluation of 
Computer security was convened to "develop ..eal iSutLns 

S r^Sle^f^th""''^ '"'i? problems"... Sinc|^?eS;oLgy 
IS replete W^th non- problems" and "psuedo^oblems'' thic 
working group elected to interpret the ' 
^ re^ solutions to real problems". 

y ; • ^ ■ ' 

This working group was asked Vo address the'^ audit ao- 
conS^?^ techniqaes for j;^lUati.on of admi^L^raMve"^ 
tv Si ^^l ^°"tributi^,of those controls to securi- 

ty. We were asked to pla^our emphasis on areas" that aJe 
not already the ^subject o? extensive coverage S tS 
adeaiacrSl we^were/also invited to comment on the ' 
adequacy of the literature. In this report we will reviAx^ 
the context or the e^ir9niner,t in which'^Se have atJempS^ 
to address the charges, i.elTthe. traditional ?ale o? tS 
auditcr and Its r'e^tionsh/p to security. It^as tS 

in"?Sis\'rL of problems do exist 

in this area and/^e have attempted to articulate thosg. 

aidi^r; problems are problems for thj 

^.X^VL. ^-Ir^^^ attempted to set forth suggestions 
that the auditQ(r ^nay find useful in responding to those 

Sact^c^" ?^r^r°^''"^ ^^'J^^ '° the'"statl 6? Sf' 
practice , th^ literature-, and the direction of ■'the tech- 
nology. The^ mlist be addressed by the broader Sta 
processing, community... We have attempted to identify theVd 
.issues and n/ake some broad recommendations, • ' 
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THE AUDITOR AND COMPUTER SECUrIt^ 

I ■ 



have.!n:'udid:f' responsibilities" o^ |e auditor 



1. protecting the assets of the 
ensuring adherance to policy 



^ f 



organ^tzation 



3.. .and -^nsv^ring the adequacy of cont^^ls and proce- 
dures 1 ^ II' . 



He has -functioned by making • tests and > examinations ' 
^and by rsfporting and rfecomniending . * ,His value to manag.ement 
• has been. that he ^provided a view thafe was independent of, 
rin addition to, and complimentary to the .view provided by 
* ^- JL ine management. Manag^eht would thus be in a Ipetter 

-poaition.to act to reduce risk or to afbce^t it. ^ / . -1 

^ . ■ ^ ' ' . . ^ . ' / ' ' 

.The auditdfr's tests and examinations have included 
c€)mparing actual* conditions to standards of good*^iraQ^^ce , 
,to policy ' or ^other expectation ,j^nd to^ the environment. 
•Variances have been sorted between good and bad, material 
or immaterial. ; *^ 

In allocating, bis resources ,^ the auditor has be^en ^ 
guided by the ]n(\andate. to ma^jimize materiality, that is, he- 
wants to deA^d%e_hiis resources in such a way 'that hip find- » 
ings^ deal with tnfe most signficiant risks to the activity. 

. ' ' ' ' ' * 

^ .Security has traditionally dealt with protecting • 
mission resources, i^e., people, facilities and data, from 
all nati^ral and* man-made hazards*. JJJore specifically, data, 
i processing security has been concerned with 'protecting, all 
of the resources associated* with the DP mission,, plus. all 
data within DP -custody. 

It should be clears that since they are both concerned 
w4.th protecting resources and assets, security and^audit ^ 
complement each other. Where the DP resource is signifi- 
cant to the organization or where' data in DP custody is 
v^ssential to the effective ^control of other signficiant 
resources then it should ^Iso^be clear that audit of DP 
security will indeed be material.. * 

However, it follows that in order for the. auditor to 
fulfill his role, vis-^-vis computer security, it is 
essential that he have a workable definition of security, . , 
an explicit statement of policy and sbodepted standards of 
jgo6d practice. As in ^other audits, he mus,t havex Access to 
*the function to be atidited and adequate resource.. He'lnust^' 
know what tests and examinations are appropriate for ,the. \ 
assets to be protected and the hazard's to which they are^ 
subject. Finally, he must. know how €b alioca-te his limited 
resource in such a way as to maximize N<he usefulness of 
his -findings, and he must^now how to communicate\:hose i 
findings in 3uch a way as to maximize management under- 
stinding.^ and acceptance. .It is the 'experience , .finding 
and conclusion of the members of the work^nq group that the 
auditor. is encountering some problems in each of these areas. 
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3, ' PROBLEMS 



r^v^Ki the consensus of . the group that sufficient- 

problems exist m the area of our charg^e to justify our 
ettor.ts, and that ^in our report we can make suggestions 
and recommendations that will clearly contribute to their 
solution, „ ' ' 

« 

• •^t.^was suggested by onfe member of the group thet .in 
audits of compute security the ^auditor suffers with a 
.def-ipition of security that ife binary and absolute. - Such 
a^ definition may result in the conilustion thaf »the 
presence of a control is always good Jd its 'absence is ' 
necessarily bad. It was the consensu^ of the group that, 
^J^^l^r^ T ^^^l organization 111 have no explicit 
statement of its/ security policy nor Any explicit assign- 

.^5-^^''''''^^^ responsibility. While in this, instance * 
^^^^^ ^'^^^^ to< standards of good practice, 
,he will likely consume more resouf^ and be ^ess etfec- 
tiVe, since the set qf good practices is larger than- the 
se^of specific practices that may have been adopted by ^n 
organization. < ^ IT 

to .^inH = ^^^^%^''^^5^^^"''^ °^ the 'group that in -reconciling 
to standards of gpod practice, the auditor is dikely to/ 
enc6unter a variety pf problems including: 

* - , 1. The documentation of ' the - standard^ of good ' 

* H^^^^® ^'^ adequate or useful for his 
pufpose; -e.^. , " (Computer Control Guidelin es" 
[1] documents general standards of g6od practice, 
but cpntains very little detail in regafS" to 
security. On" the other hand, " PiPS 31" J2] is' 
very- specific to security, -but TFTnt^nded for ~ 
managers, not auditors. 

2. The auditor is likely to find a wide;idiscre()ancy 

between ac?tuai practice and ^o©d practice . When ' 
* confronted with a variance, the auditee will say"," 
Everyone does it that way," and he is likely^ to 
, . be right. ^ Standard practice in data- procejs-^- 

sing is. more oft^.a reflection of the prabt^s ' 
-that were approi»te for eafly data proces/si«g 
. , \ , ^sys.tems tBan an #t>ropriate adaptation ^f •, 

. ^\ tradyiional standards of good practice. OfteH^'^ ' 
_ data processing mana^gement does' no.t even accept^ 
_ that the same rigorous standards of good 
'•^practice that are appropriate to the users ^are 
^}lo appropriate for them. *>his variance between 
^ . ^.standard" and "good" practice is -particuUrl/v 
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J remarkable ii>/the a?ea of system development * 

• . Even though the variai^ce is great and the " 

problem significant/ t|;e auditor isl f req.uently . 
coerced into Relieving 'tliat there^is no better 
- ' ^way, \^ . ^ . ^ \ \ 

^ ' ' , \ . 

It ^as the consensus of the gro^p that t^e auditor . ^ \ 
h^s^ difficult time achieving an effe'ctive. focus for h4,s 
audits of security procedvTres'. Thrb problem sterns^ in 'part 
from iihe literature which suffer^' from a terirtinal ^qase of 
"checklistitis" . - Like the binary definitibn^ of , security , 
these phecklists suggest that the ^presenc'e of ^ control 'is 
a.lways good 'and its abse^ice necessarily bad.^ Th^ fail 
to give proper weight to the value of the resources Jk) be 
protected, or the consequences of thfeir loss; the ,harards / 
to which those resorurces are exposed or their ^xpected . * 
rates of ^ occurrence ; the Use to which 'the sys'tem is put or 
the applications ''Which reside upon/i*t* ^ * ^ 

Finally, the working group concluded that the auditors' 
report often fails to receive the management acceptance 
and weight that are appropriate to its- findings . In 
addition to some of the items noted above ,^ a number of . - 
specific reasons for this were identified including f 

1) The reports do not discuss the Standards that were 
applied. The standards .f-6r finaripial audits are 

^ ^ "generally' accepteid" aB4 do no^ need to. be explic- ^ 

itly set forth. However, in audits of ..security 
' there , are no "generally accepted" standard's. 
Therefore, the standards that •a.re applied and.^the 
authority for them sh^o'uld be explicitly referenced. 

2) The reports fail to give proper w.ei^h^t and 
coverage to the leVel of compliance that vfa$ - 
found. Audit report^often discuss the. l^v*el of 

^ qompliance found in a paragraph and, then Spend ^ 
^ pages pn the vari^aAces. ^ ^ ' " - * 

The A^rking group articulated a "^ff^er bf ^suggestions 
which ilf hopes, that the auditor wjJJ,.,^md useful in 
improving his efficiency and ef fe'ctive^ess 
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4. SUGGESTIONS 'FOR^ THE AUDITOR 



In ^response *to the' probld|ms noted^, the g^^oup made 
suggestions ori audit focus and materiality, standards of 
practice and their dpcumentation, repCjrting,^ and aud><t sCope 
and techniques. The first' three area^s are tr^eated in this 
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chapt-er'.„^;, Audit scope and tec'lmiques are covered-^itn 
chapters" ""five through 10.' 

4.1 Aud^^j^cus and MateriajLlty ' ' . . ^ ■ . 

In order 'to maximize his effectiveness, and recognig^l* 
ing that absolute securit^^ equals 0 productivity, the 
group recommended that -the auditor use the concept of an ' 

acceptable level o£ risk" in whatever definition of 
^security he elects. Within this concept it is permissable 
'to choos^e among protective! measures rather than to employ 
them all. Management need' not be faulted' for the absence 
of a specific measure if its absence does not result in an 
unacceptable level of risk. . - . 

• It was the consensus of the working group that the 
single most important determinant' of the sensitivity of a 
system, is the use^.or application to which it is being put% 
For that reason we recommend that a helpful -perspective 
from which to view the security of a system is application 
by application. The most effective way in which to • 
maximize materiality is toVconcentrate on the more sensi- 
tive, applications. Figure_^l lists some of these types. 



* Develops or controls other applications (e.g., " 
program development systems., security sub-syst$mS) 



* 



Writes ch^s'(e.g., payroll, accounts payable, 
dividends) 



* ^ Creates credits (e.g., accounts receivable) 

' 7 , ->( 

* Controls convertible resource (e.g., inventory 
control) r- 

* Controls or contains personal, proprietary or 
oth"ferwise sensitive data 

* Controls or contains dat^ ^essential to rendering 
. a service- or continuing operation 

* ' Other ' „ . ' ' ^ 



' — y ' — 

Figurje !• Indicators of., application ser^tivity 
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^ ' In security audits, as in financial audit^s, the 
"Sutton test" is also useful for identifying material 'appli- 
, cations.for audit.*^ Wh^ifi, asked why he ^robbed ban^cs, Willie 
Sutton replied, "Because that*s W^here the money is." There- 
fore, the Sutton test suggests that securit^y auditors 
should concentrate on applications whose sQOpe incl\ades 
very high val\ie data, or are associated with high value , 
resources, 

4.2 Standards 'of Practice and Their Documentation 

-/ 

Five publications we:fe cited byxmemb^s the group 
as being of ^particular val^ue to the securi'ty auditor. These 
are: t Computer Control Guidelines [1]-, Computer Audit 
Guidelines [3t] , Guidelines for ADP Physical Security and 
Risk Managemerit [2 ] , Data Security Controls and Procedures 
[4], and Control (Objectives [5] • • 

V ; ''^^ — * 

, Computer Cdmtrol Guidelines and ( Computer Audit ^Guide- 
lines were considered to be the mosy de^f initive and 

atithorit^tive statement of th^ standards of good -praotice. 

for data processing and the effective audit of same. They 
are written by auditors 'for auditors, They^ are well- 
structured and easy to use. While the:^r scope is broader 

' than security,, they contain practices and tests which are 

''appropriate to security. . ' ^ 

. Guidelines for Physical Security and Risk Management 
in ADP was cit^d as the best source for standards of good 
practice in physical security. It also provides data on 
the rates of occurrence of , natural events that is useful in 
determining^ wh-ether or not"^ particular measure is indicated- 
While complete and well-written, this manual is ^ addressed' 

to managers. A thorough study of this manual wjlll be , 

'^re^ired by auditors who wish to use it, * / 

Data Security Controls and Procedures was recommended 
as a -good source for standards, of good practice for limit- 
ing risk in data processing. It also treats c{)nting»ency 
planning and systems^^design for security. Although it is 
addressed to management, it is readily useable by^ auditors. 

Finally, Control Objectives sets forth standards of 
good practice for data processing Management, It specif- ' 
ically treats the standarcjs fop physical security. It has 
been found useful for audits of DP practice in general and 
opera^it^^ management, including security, in particular. 
This p'^lication was prepajred by EDP auditor^ for them- , 
selves, but the auditor who is a,uditing security specif- 
ically may 'have to do some excerpting, . « 
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4.^5 -The Security Audit Report 



The working group concluded, that the style of' the 
report of arr- audit for 'computer security will have a 
slgni^cant impact upon its effectiveness. The group 
suggfest^d that thesf oliowing forma-t bight be' useful. 

' • • .■ , ' 

' Executive Summary \ ^ 

- Purpose - . > . ' 

Scope ' - ■ - . " 

. Environment ' , - - ' * , ^ ' " 
Conclusions • ■ s ■ T 

' Standards* applied * ' 

Tests performed , . ^ 

Compliance . level 
^ Variances noted ' ' 

V ' ' Recommendations 

* Residual rrsk , ♦ ^ . 

The Executive Summary should be addressed to Higher^' 
management. In addition to- describing the boundaries of • 
the audit, It should describe the key findings in such a ' 
way that the reader know^ what actio!n,'if " any , is indicated 
In spm^ instances, a thorough reading of the entire report 
Will be indicated along with .vigorous '-corrective action. 
In, other cases, it may be adequate simply to pass the ' " 
report to the auditee for his review and follow-up. The 
executive should not have to look beyond' £he summary in 
order, to determine his action. . •• . 

< 

The balance of the report should be addressed to t4ie. • 
auditee and- hi ? ma-nageipent . • Most of the corrective action • 
that will be indicated, by the audit wili^be taken by the 

^f^'^^'^^^-^^- Theref6re,. it is to him that the report 
should be addressed. .Proper recognition of the fact that 
the auditee is a l^itimate, and perhaps primary, kudience 
S*. • ^®P°^t should contribute to a style and content 
tmt IS both helpful and acceptable to him. 

- ■ Since there are no "generally accepted" standards o'f ■ 
good practice in EDP .security , the report - should discuss ' 
the standards that were applied and employed.- This action 
should reference .all D-rganization policy, standards, and • 
guidelines that were used as well as any external standards, 
that were applied. External standards should be -docu- 
mented or referenced. The authority for all external- 
standards should also be noted. 

• In order to properly evaluate th"e audit findings, 
management pst know something about, the time and effort 
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that vas^ applied to it- The .report^ must desctrbe the^ 
manner ip whith the audit was. conducted, tjrie value of the 
tests performed^ and the resource qonsuTned. An audit ^that 
involved, four people, for four wee^cs deserves more' credence 
.than pne that took one (1) person one^'(\') week. It is .not 
adequate" in a^security audit to use the" disclaimer "such 
tests ^s we f elt ^appropriate" . ^ * , 

Tlje level and naturk of 'complialKse found must be 
described JLn detail^. Tjiis. ess-ential .if managemei^t iAp 
to' be able ta properly Evaluate the findings and recom-V 
m^ndations. Variances are moife meatningful when viewed in 
tl\e light of the general level of compliance found than 
when view^ed alone. <FailuresJto .giye due' weight in the 
repprt to compliance v5jill not only detract from the • 
ingegrity of tjie report, but runs the' risk of detracting ^ 
from 'its credibilTty and creating unnecessary, resis.tance 
.06 the pai;|b of the '^uditee. . ' ^ 

If variances • and recommenda'tions are placed in the 
co;ntext^of ' this, kind of report, ijie working group belieVes 
that -they Vi 11 receive ttte best possible acceptance. 

However., the report should also in9lude assessineni^s 
of the residual, ris'k both ^wi'th and without the acceptance 
by ^nagemenu of i:he recoimnelidatiorjp. If the au'dito^ has . 
difffculty in articulating the residual risk, then it would 
be we^l to think the revcommehd'^tions through agajM . ' \ y 



TYPES OF AUDITS 



5.1 Introduction . * * 

^ • ' • ^- 

Described in ^the following chapters are five different 
audit approaches for revie\^ing data, *proqessir}g secttrity. ^. 
The five approaches are not mutually:^ e^fclusive . However, 
there are f ive/ sqpar!ate identifiable modules, each-of ' \ 
which' can be 'done, as a^separate audit or combined, dependin 
on the envftoTunent tp ve audited. The^ five audit approache 
to _be described are:;^;^s?:^ 

System Development and Maintenance Practices audit 
Application Review y ' ^ ^ 

Installation Security Review ' * 
Security Function (Data Base/Communication Environ- ^ 
ment) R^iView '\ ^ . * " * • ^ 

' Compromise ^Attempt - / - . ' . \ 
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These audit approaqhes are not treated in pri^ftv 

lI'^Tu'''^^ .'^^^-''^^^^^''^ importance, of e^ch audit module 
?tiL^ determined by the DP envif6,nmeixt to be audited. 
Since most. audit staffs are limited in' resources , Ut' i 
important that adequate t^ime; is. spferit in the- pre-audit 
pnase nrofilma -t-ho nv> .^i' . . 



^ The ar%s of audit :;,Goncern , the audit purpose, the 
audit approach (wher^ applicable), and proposed scope with 
recommended tests will be descMbed for each of tSe five 
aforementioned audit approaches. - 

• V 

5.2 Checklist,9yCRef£i:enr€§— 

.li^t "J^l^Lnr ^^^v,^"^^.^ °^ P^P^^ ^° provide- a check- 

list for each of the subject audit approaches. It was 
determined fehat there are numerous references available on 
the various subject areas including checklists. It was- 
the consensus- of our group, .howevfer, that- the besf^- single 
^ference is the Computer Control' Guidelines and the 

rt'^'^tl Gu^elines published by. the Canadian Insti- 
tute of Chart^i^ccountants. ' , 

It should also be recognized th^\ any generalized 
reference or checklist^on the subject master- must b^ 
tailored to the environment under review. There i's no 
applicable''^'' ^""""^^ common to everyone and equally 

* • ' • \ - 

The purpose of this paper is to provide a uniform 
?efe?eSSfes ""^^ supplemented by checklisti and ' other 

5.3 Approach / - ' 

\u^J 1°"" ^^""t -^^^^^ security audiS:s' it is suggested 
that, the approach be the best, configuration of all tradi^- 

^;^?echn?qLsr'?f^"'^'° '"^^^^^^ ^^p^^^^^ - ^-^^p- 

' Selective Pyotection - identify 'the key effort 

resources .fn<^:.i'poncentrfete the review efforts on how 
those resources are protectee^. ^ ' . , • 

Test - wherever possible verify procedures and ' 
-discussions through actual tests {e:g., control report 
. .reconciiaations) . • - . 
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* * Intferview -^conduct interviews with all involved 
employees and manag'ement in computer operations, 
programming, users, security, legal, personnel, etc. 
T^his is an a're^.to be stressed ;^ good interviewing 
techniques supported by adequate follow-uj\ testing 
can greatly facilitate the audit by producing more 
findings in a shorter perio(j' of time. r^' ^ 

Technical Cooperatives (co-ops) - the use of -team 
members on these audits from other organizations or 
locations, selected for their technical expertise., ^is 
a^very effective and well-proven technique. One word 
of caution: the, auditor should always -be in charge. 

These are some of the approaches and techniques that 
the group felt would be very effective in conducting audits 
of DP security. 



SYSTEMS DEVELOPMENT^ND MAINTENANCE PRACTICES' 
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6 . 1 Concern * 

(» 

In the audit communifty today, there is an ongoing 
debate: should the auditor be involved in Systefn Design . 
and Development. Both sides agree: 1) that there is a 
valid concern from both a security and control viewpoint 
that the proper develbpment of new systems and applications ^ 
is important, 2.) that . post-implementation enhancements 
are ^difficult at best to install, and 3) that the auditor 
cannot ignore his responsibility in this important area. 

It 'i« necessary in many instances to build very 
tight security routines into a system or application. 
.Thereforer, all aspects of DP security should be considered 
during design. . If- proper security cannot be provided, 
then it is conceivable ax project should be halted until 
bette^ technology jdr contro.ls are available. This is an ' 
extremely important audit. If security is not being 
built in during design, 'it will probabXy'^lWays be non- 
existent. ' • 

• « • . > ' • 

This audit approach is presented as an alternative to 
the two -extremes of the "System Design. Debate"' and as a . 
minimum lev6l of .involvement on^he part of internal 
Auditors. It is ah' approach wh'er^e the auditor can review 
the system development process, rather than 'actively 
participate dn th^e content of system* design." It is 
particularly applicable to those audit staffs that have 
ei'thei; consciously decided, not to become involved in the , 
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content of system design or because of resource constraints 
cannot cover all new development projects (large* oraan- 
izations) . " ' / ^ = ts-* . • 

. ■ It was ihe consensus of our grpup tha;fe^eviewing the - 
, management process for system design is/^ effective^ way to 
ensure coAtrol^ are built ihto systems^n an ongoing basis 
. • and^ not o«ly when the auditor is ip^lved. 

'6.2' Purpose 

. • The purpose of this audit is to determine if local ' 
management is in compliance with established procedures or, 
given the lack of defined procedures, if local management 
has established and implemented adequate standards and 
procedures to ensure t^at only secure systems and appli- 
cations are developed. The purpose of this review is to 
■determine that all aspects of security are discussed and 
that controls are implemented where- necessary during the 
, development cycle. The auditor must determine that the 
. subject of security is actually an integral part of all ' 
decisions made during the development cycle. ' ' ' > 

6.3 Approach 

The audit approach will be to interview local 
-personnel and management and to actually sample current 
and recently completed development projects and asBOciatexJ 
.documentation, to test compliance with procedures or, in 
^ • th^/ebsence of such procedures^ to determine if 'exposures 
exist based on judgment and gerterally accepted business 
practices for Sys.tem design. ' ' 

/ • 

6 . 4 -Scope ' • ' , ' . 

^ 6.4-.1' Design Standards " ^ V ^ ^' 

' ... ' ^ 
Th^ obvious place to start an ,auait;of this nature ^ 
is by a review of corporate and divisional design standards 
and a comparison o"f the local organization's procedures to 
established com^)any* standards . An important point ta 
remember is .that the auditor should recdmrnend improvements, 
to company standards as well, as local policy when def i- ^ 
» ciencies are noted. . ^ • 

During this phase of the audit,, the auditor^will 
familiarize himself witji the company policy arid the 
adequacy of the .local operating procedures*. ,Morie ITften" V ' 
than not, a review of local operating prodedtiras will be 
reflective of the actual practices. If management has pot 
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taken the time to adequately define development procedures 
and formally assign responsibility for security controls, 
it will be a rare exception to find q well cojitrolled aod 
secure environment or piroduct.:. 

The» Design Standards should; discuss physical, admin- 
istrative and technical controls in all of the following, 
areas which will ^ the sxibject matter of this^ audit: 

Organizational 'Controls---^ , 

Access Control ^ , • ' 

Phase Reviews ^ ] ^ . • 

' Testing/System Assurance ' . ^ 
Promotion Process^^ * 

Documentation * . 

Auditor/Independent Party - Involvement 
Configuration Managemen'fc? ; ' 
Emergency Procedures ; 

The audlltor should detefanine the adequacy of 'the 
0 procedures .in all of the areas* The remainder, of the 
audit will then be devoted to testing compliance to 
established or recommended procedures as they are imple- 
mented in the development cycl*e. 

6.4.^2 Organization Control " c 

The foundation of all* controls is the organization^ 
The auditor "must evaluate thee organization to detepmdne 
if it. is conducive to good security controls and develop- 
ment practices. Hiring practices, separation of duties, 
manpowfer resour'ces, skill mix and education, are all 
-subjects that should be reviewed during this audit. In 
this portion of the audit, the -auditor must detepnine 
that the responsibilities and* duties .of the using^^ functi<?n, 
programming and computer operations- are clearly defined 
and separated; that mar^power has been properly allocated' 
to key control functions; that, these functions have the 
required technical expertise; and, that ^the employees are 
being* given adequate ongoing etjAicatiqn. 

It is reas9nable fdr^ the auditor to assess whether the. 
subject of organization, control; is being adequately addres- 
. sed during the development cycle. 



6. "4. 3 Access Control 



Ensuring that accfess to all propriet^ary -DP resources, 
is limited to only those employjees with an absolute need ' 
is key in* this audit.- * A lack. Qf controls in this area 
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will expose proprietary data to unauthorized access; 
enable computer frauds; possibly result in poor data'* 
integrity; and poor documentation. , ' . 

4.-« V^^'^'^^^^J-^^^^^^^^ physical controls to limit access 
to, the fpllowmg DP resources sjiould be reviewed: ' . 

Facility 

Computer installation 

Hardware ' ii# * 

• Programs ' " " , 

JCL 

Data ■ • , 

Output reports ' ' 

All DP media 

The auditor should ensure thdt ac~bess -control is 
being considered during system design so that additional 
access or other controls can be implemented during" develop- 
ment if necessary. ^ ^ ^ . r- 

Tne auditor mus access control' procedures by 

reconciling actual employee .accesses to . DP resources to 
management's list 'of authorized personnel. The auditor ' 
must also determine if management has limited the 
authorized list to only, those with an absolute need. 

6.4.4 Phase Review/Project Contrbl 

= ^' ' _ 
A formal, detailed, and documented phase -review 
procedure is necessary if .management is to exercise ~ 
effective control, over system design. The .phase review is' 
a tool tt> provide executive management with information 
about status of projects. Through the phase review .cycle, . 
meaningful checlEpoints are established, .whereby critical 
issues relating feo development are addressed. 

Security control is one of th'ese critical issues 
which is often overlooked during bhe phas^ review for a 
variety of reasons.* ^ ^ . • . . ^ 

From a security viewpoint^ the audrtor -must review 
the* phase, review process and determine if security i& 
considered as integral part of all development projects. 
There- are many questions that need* to be answered. For 
example^ is the security department involved?^IS' the DP 
-security coordinator , involved? Is the user involved with' 
security? Is the security system tested, etc^;? * - 

The main point that th6 auciitor must adtfress is that 
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^ in the early stages aJ^ all development cycles a security 
philosophy and documented plan is de^veloped, agreed to, 
and p'erformance ' to' the* glan is monitored thijoughout the 
development cycle. The^should be adequate documentation 
to substantiate that s^f^ity was not treated lightly. 
Managemeijt? involvem^lT^^a^approach should be evidenced in 
writing. ^ - 

6.4.5 Testing/System Assurance ' - 1 

The auditor irfus^ ensure that all security controls ..^ /' 
designed into the system ar^ extensively tested. A 
. ' comprehensive test plan and docupiented results should be - 
available for .review. Security should be 'an identifiable 
category in the^tes-t plan. 

Also, during the test cycle, security exposures may 
be' created if proper administrative and physical controls 
I are not put in place to control ■ access to live data. The 
. auditor must ensure *that live data is not "used except 

under the most 'extreme circumstances, and that if ib^'is 
, .used/ controls ^ to prevent , misuse are in place. 

'6.4.6 Promotion'* Proces.s' * ' ' . . 

The promotion process is the process of transferring 
a program^ from a test status'*to a production' status . In 
.a well controlled environment, computer operations wilX 
maintai'n' ownership of all' production programs, JCL and 
associate^ documentation, and the programming function 
will maintain control of the programs while they are in 
a test , status. Promoting a program, therefore, generally 
means trans-f erring l^ntrol from the programming function 
to the operations furkrtipn.* ' 

' * *" # 
During this process, many effective a/Jministrative 
and procedural controls can be implemented to ensure' 
secpurity of y» the programs themselves, and that Security is " 
Uuilt into the programs. The following' represents a 
partial list of controls the auditor should loolc for: 

, • Using function request/written authorization ' 

- Ppogramraing management approval/authorization and 
aeTegation to programmer ^ 

^ - Operations release of programs and documentation 

based on authority , : t . . 

- Independent party review of codfe to detect errors 
and deter programmer fraud 

' Separation of test and development work from' ' 
* ' production* , ^ < . 
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- After promotion, documentation, programs, JCL, ; 
data, etc., controlled byCbperations • 

/-The promotion process Is an^ important part of the 
maintenance and developmeat cycl6. Procedures and controls 
duririg- this process must be reviewed. 

6.4.7 \ Documentation^ 

Auditors frequently encounter poor documentation 
and are advised that documentation is v^ritteri for pro-, 
grammers and not auditors. pdor documentation results 
in applications and systems that are not functional, 
effective,, or secure, and coincidentally, ' are not .easily 
enhanced, are not understood and' are not auditable. 

While it is recognized that poor docutnentation is 
a .universal problem, the auditor should not ignore it. ' 
The product of any system or application development . * 
effort must, be, an adequately:^ documented, solution to a 
problem or need. The program or code itself is ,onay 
, one part of the solution, but is often given the most . - ' 
attention because its intended audience, the machine, 
is the most unadaptable and unforgiving. The intended 
audience for the documented solution to a problem includes 
management, userd, operations maintainers, the machine 
and auditors. ^ ' 

.Auditors are an appropriate" audience by definition. 
Therefore, auditors 'should, be able to understand the doc- 
umentation and should critique it if J^y are not able t 
to understand it. • The auditor shouldensure documefitation / 
standards are adequate and are being adhered to and should 
no longer, accept the traditional excuses. 

7 ■ . ■■ ■ ' * - • I 

The auditor, must' continually review and criticize the 
lack of adequate^, documentation, 
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6 . 4 . 8 _ . Auditor/Independ^^ft Party Involvement 



- Sensitive programs/syst4ms should be subject to an 
independent review and verif icatioi) . If the auditor does 
not directly participate in system design, it is .impor- 
tant that som^ func,t±9n be designated, as the independent 
party. The aujditor must review t-he aliequacy of independent 
party involvement during system design. . 
^ ■ '1.. • ■ , • ^ ' 

6.4.9 Configuration Management 

t " ^ 

The auditor should expect to, find a management system 
or mechaijigm fjDr controlling whicji versions' of each 
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cDmpdhent are included in any ..specific integration or 

^cop:^6f Ja product system. Thia management' system should 
incl^te/an ^udit trail that is acj^equate to determine for 
any rfiv^n integration- or copy, which veVaion of a 
component was included. Tests should be -m^de ^for- the 

'.presebjCe of the system, its adequacy for the application, 
thay it is being used as intended, an'd that the audit 

■traj^lis present and adequate 'Wh^e indicated, the ^ 
conteiTt of the audit trail should be reconciled to the 

•^ content o'f an integration of a product system, 

, 6.4.10 Emergency Pro6edures , . , , . 

\ Management must have the flexibility to" substitute 
emergency procedures for normal procedures when required 
to respond to unusual situations. Emergency procedure 
will compensate ior the risk associated with extra f-lexi- 
bility by involving additional management . /%evieving the i 
^ ' procedu4:^s and actual practices intthe eveVit'.of an emer^ 

gency program fix, to prevent the bypassing of^ established 
controls, is an important pabt/of the System Devel^opment • 
Audit. • , ^ ) ' 

f • ■ - ; . ' ' . ' 

The auditor should expect to find procedures that 
^ ensure that all emerge^^ fixes are subjected' to the 

same controls after, that the normal updates are subjected 
to prior. * ' 



7.. APPLICATION REVIEW 



7.1 Concern 




There' ^'re important administr Jl:ive , procedural *and 
system controls that should be in place to provide for ' * 
• contiauous security in all applications that have been 
implemented. Ei4:her the aBsence of or deficiencies in the 
administration of these controls may lead to exposures.: 

7.2 Purpose . . , ^ 

An application review i? a post-installation analysis 
of the data processing security controls a/id procedu^s * 
that are unique to "a specific applicatic5n, Thils is i» 
contrast to otheir data processing security controls and 
procedures that are common acro?s all ^plications in a / 
compj^iter environment. 

^ The purpose of this review is to ensure that the appli-- 
cation was designed with adequate internal security controls 
and that thfese^ controls are being administered in a consis- 
tent manner. ' ^ ' 



\ 
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^ 7.-3 ^proach'. , ^ ' ' 

. Applicatioh reviews should be conducted' by internal' . 
^ auditors as an integral- part of air "functional audits of ' 
. financial arid operational areas. If a functional .area 

inMnn! °" processing, an" audit of that function must 

. include a review of the data processing related control^.' 

on4- ^"^^^^^ of the functional area is not complete with- 

•out a review of the DP application. Both parts of the 
.overall audit should be done simultai^eously : 

7 . 4 Scope " " - 

'^u'' J'^^ scoper* of an application review will include 
the, following -eight areas as they relate to a specific 
application. * . * 



Input/output controls 
System internal conti:;ol effectiveness 
• Separation of^duties 
• " Sensitive, prograltw idenlfif ication 
User satisfaction/involvement 
Report utilization! 
System documentation 
Vital record's 

Not all of these ^rea^ are applicable tp every* appli^ 
plllT^ ^""^^ described briefly on the following 

7.'4,.1 Input/Output Controls 

The system oi^ application should provide adequate 
controls to ensure that only what' was -authorized wa? pro-^^ 
Shf^^^Il ^" entirety; nothing mor^ and nothinSvIes^ 
The auditor must , assess the adequacy of the controi:tech# 
niques and determine that they are being used as appropri- 

• 7.4.2^ System. Internal Control Effectiveness 

The auditor ftiust^ e^^all^ate and test the adequacy of"" " 
^ internal edit and audit routines to ensure the detection 
or prevention of qt^estionable or- invalid 'situations . " 

The auditor .must' determine if adequate "internal • 
controls exist. by reviewing system documentation, inputting 
.test transactions,, questioning users and reviewing 
exception, and .control reports. The key here is" to test 
whenever possible. • ' . ^ - 
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7 •4.3 Separation of Duties 

•• ' ■ ' ' ' ' ' -/ 

. It IS clear that the security of any applicatipn is 
dependent on , the proper separation of tijiose duties normally 
performed by .the '\iser> pifogrammin^ and operation^ functions 
For ex-ample, in an accounts payable .application, the user 
should ''hbt program or be able to execute- the application. 
The prbgrammer should not be allowed to input ' li\^e data 
or access master files. The operator should not reconcile 
cpntrol totals. Refe'f to section -5 . 4 . 2 . 2 for a' further 
dis^.ussion on separation of duties. 

' ^ ' / ; * . ' 

7^4^4 Sensitive Programr Controls 

There may be a need' for additional controls, for 
programs where there' is an exposure to unauthorrzed ' * 
manipulation of program code for the purpose of mis- ^ 
appropriating company asjets. An example ot an Additional 
control' .would be an ind^endent review of evefcy changed 
line of coding made to the accaunfcs payable checkwriter 
program. Such^ a review would -not be necessary for other 
programs even within the accounts' payable application. 
Tjie audi^tc^ should determine the "sensitive progirams" 
'ih an application and'ensure they, are provided with , ^ 
"selective protection". ' " 

7.4.5 User Satisfaction/Involvement' ' • ' . 

The users should be questioned^during this audit * 
to 'd'etelrmine if tbey are^aware of known security def icien- 
cies that have not been ade^juately resolved. ^The auditor 
must determine if the user linderst^rids the system^ and is 
truly involved in "changes to) it. , * - 

7.4.6 Report Utilizatidj 

* • f 

" ^ * * / 

The auditor should'* determine, independently' from ^ 
programming document at ion, the control reports ..available 
from the system and determine i,f they are used.^ , ' 

-^•^ « ' 

7.4.7 System Documentat«.on ^ . 

' The auditor mu^t r§view the adequacy 'of 4cxcumenta- 
t-^n;^^aiid make conat^uctiVB and realis^^c sugg.estions . 
Without 'adequate documentation^ ,a system is difficult 
to* enhance, understand, and, audit It is impprtant that 
the au'Qitors insist upon compliance 'to documentafeidn 
standards. Refer to section 6.4.7* for a more complete 
discussion of documentation. . " -* ' 
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7.4.8 Vitai Records " ' . • 

' During this part of' the audit it should *be determined 
that the files, programs "felank forms, etc., 'specific • 
to this' application ha-^e been incorporated in, the instal- 
lation 's contingency plans. ■ , ' - *5 



INSTALLATION SECURITY 




8.1 Concern 



^ There are Various levels on rings (see figure 2) oi 
security that provide a good security posture in a DP 
environment. A weak control in any of these areas may 
l^d ^ security exposures. The specific concerns 
in this audit are: 1) unauthori?^ access or modification 
of data, 2) unauthorized use of dataT^rocessing resources, 
-3) misuse of authorized^ resources. 

8.2 Purpose 

The purpose of this audit is to evaluate the admin- 
istrative, system and physical .controls" in all of these 
areas to provide management with an assessment of the 
security posture of the installation or organization under 
review. y ^ 

8.3 Approach^ ' ^ . . , ^ 

In ^ multi-site organization, the auditor should first 
seleot the installation or organization' with the greatest ' 
exposure. Inuring the pre-planning stage of the audit, 
the auditor must carefully describe the installation under 
review 'to ensure that the audits scope does, not omit any 
significant areas and that the audit team is selected and 
prepared'-^for .the unique technical aspects "of the instal- • 
la,tion. Whenever possible, team, members possessing 
required DP expertise should be selecte"d. This not only 
facilitates the audit, but provides a val*Uable training 
groOTTd for DP frofes&ionals.- The audit ilfroach will be 
•a combination of employee and management interviews, 
documentation reviews, and detail testing 'to support oT 
disprove interview results. Interviews alone ar^ not 
suf.^icient without substantive testing. ' 
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8 . 4 Scope • . , " ' . 

The s^ope of a DP installation security review in a 
large installation may look' very compLe^x', but it can be 
divided into four functional audit techniques: 

1) Procedure reyiew" ' 

2) Organizational control ]^view 

3) Access control review 

4) ^ Contingency plan review. ^ 

It will be the intent of this sufe-chapter to identify 
all audit^ble areas and expand on only those that are not 
well defined in the literature, ^ 

The scope of this audit may be further broken down - 
a,s follows: 

Procedure Review - * . ^ 

Sta,ndar.d Operating-^ocedures 
' Self-evalua-tions (performance and results) 

r Organizational Control^ ' 

Responsibilities 
Separation. of Duties 
Termination Practices * 
Job Rotation » 
Vacation Schedules • ^ 



Access Control 

DP Resources 
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Space 
Media 
Equipment 

Programs ^ ^ ^. 

Documentation 

Procedures - ' ^ 

Protection Techniques ^ . 

Physical Security, site, facility/ ^ 
DP installation 
Classification System 
Media 'Control 
DP Operations 




■f , - Remote Computing' * ^ 

/ \' Buik;;;T)ata Transmission 

Program Controls- ' 
^ ^ - ' [Encryption 

•Contingency' Plan * . 

/' Emergency V Plan » * 

Backup Pl'an * ^ . 

Recovery Plan . ' 

0 ' ' Vital Ilecords Plan - * 

8.4.1 Procedure Review 

An installation security revifew should begin wl.th a 
reccfriciliation of 'local- procedures 'with 'standards and 
guidelines. 'If local- procedures agree with standards and 
• guidelines, this mdy be taken as evidence that the oper^a-^ 
tion is consistent with accepted practice. Hdwever, the 
auditor must still reconcile actual practice to accept^. 
If local procedures do -not a,gree"with standards and -guide- 
lines, this may be an indication "that local management is 
not devoting adeqvfate attei\tion to DP security. 

.The auditor should review ?he local operating 
procedures' to determine that they are adequate and that ' 
they explicitly define responsibility. ^ Jn additian, .the 
a-uditor should request any management self-assessments on 
the subject of DP security. 'Concerned management may 
have- initiated a self -review or peer, review program; ^ 

6.4.2 Organization C^^ntrol 

8.4.2.1" Security Responsibility Assignment ' 

' Early in the r^iew, the auditor must make ' a deter- 
min'ation that 'responsib^ility for the prqtection of all 
resources H^s been exfj^-icitly assigned. m addition, ^ach 
emjiloyge should have been assigned respon&;Lbility for ' 
protecting resources within#his ownetship or custody, for * 
noting variances and for leaking appropriate and timely 
oorrective action. ' Whe:?fe indicated- by^ the "^x tent oe^ ' 
sensitivity o£ resources ^or operations, staff responsibil- 
ity for security should have been assigned. 

8.4.^2.2 Separation of Duties 

Separation of duties must exist between'' DP and its 
users, and within DP and its users. This separation' 
should be such that: ' 1) individual has access "to a 
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sensitive combination of resoui;ces, 2) no incTividual is 
in a. position to fail and conceal, 3) each individual's 
* key aqtions are dhecked upon by-^' another individual who 
is ohry doing his assigned, job and 4) each individual 
can be held « accountable for his actions. 

Th§ auditor should ' examine organization charts/p%r- 
formanqe plans and such other evidence of assignment and 
duties ^as are used to determine that proper separation 
has been provided for. He should examine audit trails to 
, insure^ that it is congistently^malntained , 

^ 8.4.2,3 Hiring Practices, Job Rot^tion,^ Vacation Schedules 
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other organization controls sucKas these must also 
be reviewed: They are second* nature to the auditor and 
warrant no^^further discussion, except to say that they are 
.equally important in the DP environment. 



.8,4.3 . Access 'ControT 
8.4:3.1 DP Resources.;' 



Access contrdl to the'site or.facility, the DP ^ 
instal.lation, and' all DP resources must be reviewed. " This 
includes'f^space, media, equipment, documentation procedures, 
and programs. Techniques for access control to some . 
of these resources will be discussed separately. Where ' 
appropriate, the aUdltor must determine, fro.m the DP 
installation profile, what DP resources are critical- and 
concentrate the review efforts there. Logs or journals 
of access should be in place as required to fix accofnt- 
ability. Tests s^hould be made to determine that such 
logs or journals ate routinely ^reconciled to expectation 
on a timely basis. • • _ * 

8.4.3.2 Protection Techniques 

* • * * ^ * ' 

'8.4.3.2,1 Physical Security, Site, Facility DP Instal- • 
latipn > ■■ 

Facility, ahd insjb'al^lation access control are the 
first two levels of protection. Only personnel whBSe 
•jobs are within the facility or installation should be 
permitted normal access. All athers should be admitted 
only under additipnal rules. ' The auditor must test actual 
acces3 to the authorized list. ^ 

8. 4. 3^2. 2 Classification System * ' • ^ . 

One important requirintent for maintaining accei^s 



contrei and other DP security 'controls is the adequacy of 
the. system for identifying sensitive resources. Without' a 
classification system for identifying the relative 
importance of the resources to be protected, a DP security 
program will not be -cost effective. The auditor must test 
the classification system to determine that it is under^ 
stood and working, that resources are being classified 
correctly, and that where applicable, classification 
termination dates ^are being assigned and observed. , 

8.4.3.3.3 Media' Control 

In order .to properly safeguard media (tapes, disks, 
etc.), it^should be labeled with its .classification and , 
each' classif icatipn^hould have a minimum level of re- 
quired controls. example, V media labeled "secret" 
may be inventoried semi-annually .while "top secret" 
media* may be inventoried weekly. A separate access with- 
in the DP installation should be available for stojring 
media.. An authorized access list should be available 
ajid an audit of access to m^dia should be available. * 
The auditor may wish to reconcile the\ audit trail of 
accesses to the authorized access list. * - 

8.4.3.3.4 DP Operations - Input/Output Controls 

There must be adet^^te controls to insure: 
1) accountability, 2) ^at on^^'authorized DP jobs are 
processed and, 3) that^he resultant output is distri- \ 
buted to only the authorized recipients. There are 
humerous ways acceptable for providing these controls.. 
Reviewing the DP operations function for the presence, 
adequacy and reconciliation of these controls is an inte- 
g-ral part of this audit. . . ' . 

8 . 4\ 3.. 3 • 5 Remote Computing * I 

^ 'Security controls in a remote computing or inter- 
active environment are important because physical locks 
and keys alone may not provide for adequate accountability 
or deter unauthorized access. The minimum controls to be h 
reviewed in a DP installation audit include the following: 

« 

l^ser Identification 
.•f'^^ Data-Access Controls - ' 

Terminal Identification 
System Security Administration^^ > 
Audit Trails ^ - ^ —VJ 

^ Terminal Security * 

Privileged , Sign-On Codes. 
• -'Output Controls 
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(.see Security Function Review, chaV6^-9)* *^ 

8. 4^^3*3 ,6 Bulk Data Transmission 

I' • — ^ 
Data is often transmitted in bulk by. mail or 
electronically. Depending on the data sensitivity and/or 
classification, certain controls may be indicated, ,For 
example", ."secret data" to be forwarded by U. S'. M&il may 
require double enveloping to conceal internal classif- 
ication identification and registration with return receipt 
' requested* 

All bulk data transmission of ^classified data should 
be approved in writing^ and an audit trail maintained 
indicating date,, time, sender, approver, recipient and 
acknqwleagment as appropriate. 

8.4.3.3.7 Encryption 

Enciphering" may be indicated for very sensitive data 
that must be* passed outside the control. of its owner. 
Only algorithms with known properties such^as- the Data 
^ Encryption Standard algorillhm should be employed. The 
implementation of the algorithm shoxiiLd be .appropriate to 
the application. In reviewing the use of encryption, the 
auditor should remember that there' ^re costs in terms of 
.system performa|ice that must be cfonsidered. 

- The auditor must test to ensure data is encrypted 
where necessary and 'that good encryption procedures in- 
cludiixg key handling have been implemented. ^ ^ 

8^4.3.3^8 Program Controls- 

Access controls must also be in place to protect 
programs, JCL and related documentation from xinauthorized 
access. A program may be ' |)roprietary for its intrinsic 
value or it may be "sensitive" from the standnoint that 
unauthorized changes could facilitate or conaCal .itjisap- 
propriation of company resources. In ^either case, .it is 
important that^ programs and related JCL and documentation 
be protected from unauthorized access! Controls^ should 
be adequate for the integrity of the change history." 

8.4.4 Contingency plan - - ' 

. ^ Dujsing this review the auditor 'must determine that ' 
the installation is prepared in the event of any natural 
or man-made disaster or. any other happening that would 
, severely .interrupt normal business operations^ The 
auditor should expect^o^ find p;Lans for detecting and 
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, limiting .emergency events such as fires or intrusions - ^ 

(emergency plan),; accomplishing critical jabs on a timely . 
basis (^ackup plan); recovering mission capability 
(recovery plan) ; and a plan for identifying and^jgdtecting ' 
data- vital to cystomer, employee, or, sto<>kh,61der^^ities / 
data related, to national interest (vitaL records plan) 

'The key to successful^ contingency planning is periodic 
testing. It can reasonably ^be assumed that a contingency 
plan will not, be .effective, if; it is no-t te'sted and up- 
dated annually. The area of contingencies should not be 
left to chance. The auditor should look for evidence that 
^the plan has been both tested and updated. 

* 

9.-- SECURITY FUNCTION J^EVIEW 

^ r * 

e 

9.1 Concern • >i - * * 

The security department ot function provides for the 
articulation .of security policy, the allocation of securi- 
ty resource, the definition^ communication, "and adminis- 
tration of security rules, -the. tiitiely- recognition of 
variances, and the recommendation of corrective action. 
It is a* staff function serving all levels and functions 
of management. Depending on the nature and scope of the 
system it supports, this function. may be responsible for 
extensive computerized data and procedures for carrying 
out its responsibilities.- Its data may include state- ' 
ments of authorization, system or application acfcess 
.rules^ and notices of variancee. Its' procedure^ may 
include programs for applying or maintaining access rnales,' 
or. for communicating or analyzing present rules or T 
notices oT variances from them; ^ 

This staff is responsible foir the implementation and * ' 
operation of all security controls that are geheralized 
' across applications and operations. It may be viewed as 
a veridar of access control, monitoring and, advisory 
service to applipations, . and a$ a vendbr to, and customer 
of, operations. - * * ..^ ' 

The proper functioning of this department or, staff, 
a^nd the/ integrity of its data and programs, may be vital 
to the uniform, timely'and consistent application of all ^- 
security controls and procedures. 

'9.2 Purpose * - ^ " ' - ' 

The purpo)se^of the security functidn review is, to 
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insvire' that: its facilities and organization are consis- 
tent with good practice and the needs of th^ installation 
and applications; its resources are consumed as manage- 
ment intends and that using departments are receiving 
satisfactory service that its actions are consistent with 
management and' using depar^tment authorization; that its 
audit trail is adequate to demonstrate authorization, 
accountability, accuracy and corapleten-ess ; and that vari- i 
ances are dealt with on a timely bas'is. 

This review is indicated .whenever significant security 
func-tions or servi^ces are. generalized across uil\ig depart- 
ments or applications. such as in time-sharing ,Ldlta-base , 
or interactive environments. • ■ ■ • 



9.3 Approach • • t ,. 

Depending on the size of the" installation or system 
to be audited, a review of the^ security function may be \ 
a module of another audit (e.g., a DE installation audit)' 
or It may be done -as a stand-alone* audit . Security Wy be 
viewed as an application and audited accordingly . (see 
Application Review, chapter 7) . The same audit approaches 
and techniques should be used in this audit as^ discussed 
in the prior audits. ' , ^ . 



9 . 4 ScQipe 



m 



An outline of the scope of thi.fe audit* 'is as follows: 
General 

Responsibility l^^inition * . 
§4:a[ndard Operating Procedures/Users Manuals' 
Self-Reviews "of DP Secvurity 
Educatiorf 
^ Employee Awareness ' ^ '[ 

Sectarity Administration (Interactdve) - 

Administering Security Codes ' , 

' Monitoring 

Reporting • ' ' • 

'>Yio,lation * 
Critical Transaction Usage 
Terminal Authorization / • . 

User Authorisation - . 

User Termination - , . " 
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Access Control 



^ ^ DP Resources . , - 

Space . * ^ . - - . ' 

Media • ' ^ 

^ ' \ Equipment . ' * , ^- ^ 

i Documentation 
If'^' Communications, * * . ' . 

Contingency Pl^s - ^ ♦ . 

Emergency Plan 

9.5 General « ' ^ • 

9.5.1 Respons'ibility ^ 1 

The security function. is generally a staff function 
responsible for overseeing and monitoring DP security. 
The auditor must ensure that this function has been 
clearly defined. . ■ ^ ^ 

^^The ^security function serves usfer management by 
administering access rules within. the system. The auditor 
should look for adequate audit tools to erjsure all admin- 
vistrative activity is as authorized. 

9.5.2 Standctrd Operating Procedures/Users Manuals^ " 

It is t;he responsibility' of the security function to 
ensure loc^l security guidelines, operating procedures-^ 
and users manuals ajce written. and properly maintained* The 
auditor sh<^)uld review these documents ; ^ as iii^icated, and 
test for cfirrency. " ' ' ^ 

9.5.3 Self-:Revifews or Peer Reviews 

The auditor should request the^i^egults of any self- • 
reviews or peer reviews ori the subject of DP security 
and the corresponding action plan.s aiid progress to date. 
An analysis of »*self-review information will give tlie 
auditor a gooQ insight into the organization and problems 
identified/ but does 'not' relieve him of the responsibilijtj^-'' 
to complete the audl't.' The auditor may, and should ,'^u^"e 
the results of the self -reviews .where applicable in his 
final 'report as long as the source of> thp information is 
acknowlejlged and the resulting comments are put \tn proper 
perspective-. » - * . 



7-30 

^ 142 



9.5.4 Education 

It. may- be the responsibility of the security 
function tjo both condiict tairlor-made education courses 
for the. line f unctions\ and to ensure that these func- 
tzons take full advantage pf all applicable security 



courses- on DP security 
3f .such responp:^bilit 
syllabus, and rosters 



Evidence of the performance 
including class- schedules , 
should be reviewed. 



9. 5. "5 Employee Awarei^ss - - * 

This IS perhaps /the most important agpect of' the \ 
security function's job. Because the subject of Df ' 
security maj be viewed as negative/the auditor must 
determine what the security function is doing to make it 
positive and to* maintain employee awareness and concern. 
The possibilities in| this' area are limitlfess. Posters, 
suggestion programs,! inf ormal*awards , breakfasts, lunch- - 
eons, guest speaker^ and executive management speeches % are' ' 
only a few of the pdssible ideas. Instead" of guards only 
•noting violations, they could leave a thank you note for 
securing proprietary data. The content of the awareness- ' 
program, might point out the value of assets and the- 
impqrtance of the employees' role in protecting them. 

In any -event, this is an important area. An effective 
security program is not possible with6ut the concern 
•commitment of . the employees.'. , * " 

. Security Administration Unteractive Environment^^ 

Generally, \in any interactive system someone, or a < 
group, m ^a staff -capacity^ has been designated the security 
admxnistratpr. The proper performance of the associated 
responsibilities is important to maintaining effective' . 
system security. The responsibilities of a security 
administration may include: . . ' ' 



Authorizing use of system resources' 
Administering security codes 
Monitoring user activity 

- Violations or variances 

- Critical transaction usage 
Terminal authorization 

User authorization 

Data access control 

User- security education . * 

Conti'ngency* plans 
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The audit9r must test the security administrator's 
performance in all* of these areas. The auditor should 
^ expect to find written evidence to support the proper 
execution of these tasks/ - ^ - . 

" r \ 

Krt area of the security administrator/ s tesponsibility 
- that is often overlooked is user involvement, rhe security 
administrator should^ mrftiva-bfe user involvement, under- 
standing, and perhaps most fcnportant/ feedback. The 
security administrator shduiSC continually review user 
^security practices. - \ ^ ' 

9.7 Access Control 

In this audit the- security administrator's role in 
access control or the monitoring of access control must be 
evaluated. Refer to section 6.4.3 for more detail. The 
security admini^rator is generally responsible' for ^ ' ' 
advising managenfent of any control deficiency. 

Contingency Plafi 

The security administrator's role in creating, imple- 
menting, and ^ evaluating contingency plans should be, ' 
reviewed. Refer to chapter^. 4 . 4 . Th^ auditor should 
insure that proper treatment of the security fi^nc^ifon is 
. included in all eontingency plans.- 

9.9 Stin\maty * - 

The .securitY administrator's job may be viewed ^a's 
writing security procedures, implementing them and then 
reviewing compliance.. Aivy control deficiencies noted 
during a security audit are a direct i:eflection on ±he 
security administrator 's job p^formance.V unl'ess'they had 
been previously noted ^and escal^ed to the right level of 
management for ifesolution. 



10. ,CONTROLtiED'' TESTS/PENETRATION STUDY 



10.1 Concern ' ' ' -rc 

The purpose of this audit is to resoj-ve ^fundamental 
and reCur'ring problems and exposilres that auditors* have 
continually poinbed out to management that have not been 
resolved. Because 6f the types of problems noted in 
chapter 3, it often happei^s that management does not pay 
attention to tjie auditor's concern. Management may have 
an attitude such as, "it can't happen to me".' 
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10^2 Purpose^ 



Tha purpose of this test is to (Jtamatize to t^e 
executive management thd need for I>P security by per- 
petrating an unauthorized act. ' . <• 

1 ^ ^ .V 

10.3 Approach ^ ^; 



The auditor may. use his knowledge of DP control 
exposure,^ but should not use audilT^rivilBge . At the 
successful completion of the test, the ^auditor must be 
able to demonstrate beyond, the shadow of a doubt that the 
compromise could have been perpetrated by another * ^ 
employee or an outsider. -The auditor must be able to ' 
prove audit privilege was not a factor. 



: The chknce of success for an undetected compromise 
should bebetter than 90%, since if the attempted 
compromigfe is discoyered, the opposite effect of what 
was intended will be accomplished, not to mention embar- 
rassment to the auditor. " ' . • ' 

• ♦ 

Such a compromise plan should be enacted 'only with 
the concurrence of audit and executive site management. 
The test ■ifflj^t be controlled to prevent the auditor froif 
b,ein.g__put-,in a situation where- he could perpetrate^ a- I 
'realj&i*aud without detection. .. • • V 

n-'^f^^^P concluded that this is an effective. But ' 
dang^etou^ approach that should be .well controlled and 
carefuLly planujsd as a last resart. .^^^ 

•It IS, however, a highly effective technique, when 
done in a truly professional manner. 

10.4 Scope 

V ; scope in this situation, i's ' limited only by the 

iMividdal^|s imagination. The following, areas 'represent 
pob^iMAities for a penetration study. Each of these 
potential areas will be discussed briefly on the following 
pag*s. Any penetration .study is unique ^£9 the envirdn- 
mentand must be assessed on.\ts own merits:' ' 

' 1) Appiiciition programming ^ ^ ' , 

2) DB/D(Z lystems'^ ' ' ^ 

-'Is 3) Information security ' . ' 



10. 4.'. 1 Application Programming # 
, ' Assign an BDP- aUditor to application programming with 



0 



» the instructions to attempt to perpetrate a fraud without 
detection by manipulating progr^ co5e. The applicatipn 
to be selected should present a hi^h probability of 

''success (e.gl, payroll). This approach is equally appli- 
cable to a batch or an interactive environmentf. , 

ip.4\^2'^ D^ta. Base/Data Communication Environment / . 

• Either *-by posing as a usdr^or' actually working iri a. 
sensitive user area, the audl'E?5r should attempt to bypass 
system and administrative controlV in an undetected 
manner to misappropriate company a'Sset^. This approach 
generally requires expending ^enough tfme to thoroughly' , * 
understand the application and surrounding controls. , ^ 

||^10.4.'3 Information Security ^ \ • 

This approach is applicable where the information-^ 
itself-*is highly proprietary (e.g., research and deyeloW 
ment environment) . The purpose is to bypass controls 
and obtain highly proprietary company data in. an undetec- 
ted, manned.' The same approach cfan be used t<j prove the 
vulnerabiXijtjf..^ this'^ata to unauthorized inddif ication 
or destrijfit|^i^ /A simple: and effective application of . • 
this approlc^^might include an 'auditor making -after # 
hours toyrs i'ii terminal^ ^fooms lookir%* for a password 
and/cJr a user'^ Ijanual carelessly left behind'. Subse- 
quenrt access atis^p^ts frdm a ^emotB^pitminal using the"^ 
user'§ manual, ar\d sigri-on password./ will mqre than - * 
Jikely yielcf intere'sting results and proVe the need for 
greate^'^c^;;i^^ ' V.t , ' ^ 

The k^y "to thxs^^approach JL's ot^ain ^u^ndetected ' 
access t9miftp|>rtaAt 'infb^ whzle %eing unauthorized, 

and by not%^ng aUcfit jpr^i^lege.y 'Being able to ^ demon- ^ 
strate that ^yone (emp:j:6yee^*^or cleaTner')^!^ \\yho has ^access • 
to the building, t:ould have *^b:tain^d'^tTgLu€^^^ 
to the inforiaation is key. ^ 



10.4.4 Summary 

Unauthorized penetraticyis. While, iinqrthodox / are - „ 
valuable ways to demonstrate the Auditor ' s . concerns to 
management, when those concerns itare fundamental, recurring 
and are not getting management action.' 'HoWeyer , * they re- 
quire extensive planning, and sometimes, ifelatively . 
expensive devotion of resources wiji^^o guaranteed pay- 
back. Penetration' attempts kre alsoVisRy a^d/prove the' 
auditee's rather than the auditor's case. If unsuccessful^ 
This is, not to mention the .possibility, of Ipss of credit-./ 
ability. , ' \ * * * * - . 



^ ' 11- ISSUES FOR TH^ COMMUNITY 



The working group concluded that there are at least 
• issues to which the data processing community must 

address Itself in the comirig years. • These issues can be 
•expected, to have a significant, if uncertain effect, on ' 

the security and auditabi'lity of 'systems. They^re'the 

implicati^ons of technology advances, adequacy of the 
.literature, and the state-of-the-practice of data 

processing. 

11.1 Implications of Future Technology 

There^are several directions that are evident, in the 
technology that can be expected to affect the secfuritv 
and ajditability of data process^ing in the futur.e. These 
include the increasing density and portability --^f media, 
mass ^storage, and distributed systems.* 

As the density with^which we. can record information ' 
on media increases, the portability of the data goes up. > 
This means that the exposure of the' data to ■th6f t or 
conversion will also increase. At fehe^^ame time, smaller 
volumes (e.g., cartridges for the, IBM Mass Storage System)* 
are being introduced. Large quantities of data can be 
recorded on volumes small enough to be "easily secreted" • 
on a person. . ' . , . • , 

'This tendency is offset in pa'rt by the* Introduction 
of. mass storage systems wh'ich enable us to move even - 
larger quantities of -data insrde the control domain of 
the hardware. The effects^of -this will, include a reduc- 
tion m manual intervention with the 'concomitant 
opportunity for error, and ^n increase in the' uniformity, 
consistency, and "timeliness of gonti^l. However, since* 
more and more data will b6 subject to a single event, 
data-base back-up procedures will become increasincrfly. 
important. . . . ^ •'•^■'^ i . 




*Editor's |Iote: Other small volume .storage devices exist " 
in the marketplace. The identification of this particular 
one does not iipply, recommendation or endorsement .by the 
National Bureau of. Standards. — ■ 

] • . ' 
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Distribution of systems over geography will reduce^ 
the •amount 'of resource subject to a single event • It 
can be expected to reduce communication cost and improve 
response tim^. On the other hajid, it^annot be ^Scpect^d 
that management control will be as uniform or* as effective 
over a 'Sistributed system. 

Obviously, some of these technical directions are * 
inherently positive. All can be dealt with given proper 
attention. ItVas the sentiment of the working groups 
that, management needs to' be alerted to the implications . 
and possibilities of these technology advances. 

11 .2 Adequacy of the Literature 

It wa3 the consensus of the group that the liter- ' 
ature for auditing data pr<:>cessing .security is adequate, 
in the sense that everything is -written down somewhere.'* 
As mi'ght be expected in a. new disciplii^e, the* lj.teratur6»^ 
puffers from s'tyle and orientation, lack of audience 
'sensitivity, volume*, and absence o£ 'authority . 

The style and orientation of the literature often 
obscures its content. Organization and structure is 
different for each souroe^ Reference is seldom made to 
models ©restructures used in other sources. Not only does 
this make it difficult to relate material from separate . 
sources, but i|: makes it almost impossible to '-test any 
source for completeness^^ - • . ^ 

/ ^ . ^' 

Emphasis is .often placed* upoh examples, implemen- 
tations and procedures,, rather than on objectives, 
princj-ples and guidelines. Thi&-places tTie"r es poll sib iiaty 
for identifying and articulating objectives and principles 
on the reader, dates the material and obscures its 

applicability to new^ media -or technology. 
* , 1 ^ . • 

Most of/ the maJ^rial in this area is written f-or 
managers rather than auditors. Often this makes the 
material less useful tp th^* auditor. Soifte material is 
designed to attract ^he. largest possible ^audience . It .can 
liardly be expected to se^ve 'apyone well. " Even th^t 
material which is designed/ specif ically for auditors 
juay not say so> so- that eveii the material which is useful 
and appropriate, may be drfficult to find. ^ 

There' is 'a plethora o^ data bein^ published . While . 
this may not appear -at first glance to be a problem, 
it p^^ces upon the reader ^a Requirement to sort the 
readable, useful .-^nd applicable from the other ninety 
present. This process is complicated by, the fact that the 
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credentials, experience ari^ .claims to authority of th^ " 
author are frequently ijaadeqaate' or unknown! ^ ° 

11.3 State-of-the-Practice - ^ ' . 

of-the^^rr^aS'i'fda^a"^* extremely critical of '^the , state- 
to be audit o? seSur!t? ojob?!™,"?- Z^^" °* ""^^ 

operations-, it s2r\o^:s^J^^j;;s%e°L'^^|JJl-j^,. 

•p^'Su" and"'gSau'?J/"^°'^"*^";' while'neglectin, 

■tra'5t^°^S^a?d'?*??S?%?ortirej|ec\^\"/?,iT'.""'^^°'" 
from a percettion on the o^^l^r I ■ * "'^ tools, and 

are reSistan? to cSan* /?odav* ^T^^J^^ programmers 
of the brief! historv S"-'' ^ ? practj^oe. is the result 
hlstSJy^spenJ ^laS^f^rir- °' "^hat ,. 

that -wLKed o^ on/joTayaliL 'The'^prJ^^ISJ^^har^ai"'' 
?^^oS?ceK^g'^?|4:r^"- ^---JSlSr^^Sd^y"?:^ 



the reluctance of its practitioners to accept change. ' - 

th^i- ^^f "°^^ing>^oup was unanimous in, its conclusion ' 
that data processing management must mo^e with all ' 
deliberate haste to . improve the si-^i-Jr.^\Z Z- ' 

i-nr7^e--ii-£»^^ 
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programming tools As such, they must be implemented 
by managers and not programmers, ■ 

The use of the. new management techniques will require,^ 
and will be facilitated by the development. of new tools 
to support programmers. These new editors., compilers, ^nd 
J.ibrary managers must support the role of manager:5,in 
authorizing, naming, reviewing and reconciling programs 
They must be ;restrictive' and controllable "as opposeia to 

permissive and flexible. 

fo - ♦ 

It was suggested that progr,ammers are not as resis- 
tant to change as their manag^emerit perceives them. They ^ 
are at least as flexible as their userS. Li]^e tl^eir, users,, 
they will respond and adapt to new management expectations 
and improved tools. ^ • 

. . ^ ' ' 

The most urgent itifem^ on the agenda of the dat^ proces- 
,sing community is to learn to build auditable * sy3tems in ^ 
an auditable way. / 
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. ^ EDITORS' \NOTE • 

A^^brief biography of the Session Chairperson follows: 

Clark Weiss*man is Deputy Manager,' Research and Development Division 
and Chief Technologist with System Development Corporation, He is 
responsible for the corporation's independent Research and Development 
(IR&D) program. During his t^nty years with SDC he has led^^the corpo- 
,rati6n into a number of advanced technology areas, including programming 
language technology, operating-system design, time-sharing, and computer 
system security. His paper, "Security Control in the ADEPT-50 
Time-Sharing^System," which was named the outstanjiing paper at the 1969 
AFIPS Fall Joint Computer Cpnference, is one of the original early » 
contributions to the theory and methodojogy of computer system security. 
For three years he managed SDC 's* Systems Security Department, He 
directed a large number of seccH^ityrpenetration analyses for nearly-all 
commercial computer systems and a study foir the National Bureau of 
Standards on applications of, the NBS, data-encryption standard. Earlier, 
he directed the corporation's ARPA-sponsored research and development 
activities, whtch included several studies relating to the design and , 
applications of computer networks. He holds a degree in aeronautical ! 
engineering (Massachusetts Institute of Technology, S,B,), He ts the 
author of the 196J LISP 1 ,5 Primer , also published in a Japanese edition 
in 1970, He is listed in Who's Who in the West, and has been active in 
the, ACM, being a past Editor of the OS Department of ACM, 



' - The charge given to this session was: 

PROGRAM INTEGRITY : What are the audit Approaches and techniques 
for evaluation of program integrity in an ADP envi r^onmenj ? In- 
clude consideration of operating systems, data base managanent - 
systertis, and application programs, , ' ' ' " 

- Program integrity has, been^ defined as that state in which the ^ a 
software is logically complete, and correctly and consistently performs 
the task for which ft was designed and tlo more^. It is within this. , 
context that this session should consider the problems associated with 
evaluation of program integrity, < !> , 

/ - > - j f \ I ♦ 

This sfes.sian is. .to identify the audit approaches and techniques . , 
currently available ^r needed that would.prodi^ce an' effective evaluation 
of (1) the control^ exercised by management to ensure program integrity 
'durpig software development, and (2) the operational reliability and 
perl'ormance assurance of software design and fmplementation. 



; 'The consensus report that follows was <ieveloped and reviewed b^ 
the ^e.rftire membership of this session, ' ' : ' 
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Program Integrity Assessment ^ 
A Concensus Report^ 

Clark Weissman 



1. WHAT IS, PROGRAM INTEGRITY? 

V 



&^ing to grips with program integrity requires definition and 
assessment of both terms—prbgram and irftegrity. ^ In 'the broadest 
sei>se, a program is synonymous with a system of programs anjd includes 
control software/operating systems, data base managemiht systems, or 
applications programs. Furthermore, programs are "organic" in that 
th^ exist in , different forms throughout their life cycle, ^from 
requirements^ specih'cations. and design, to source and object code. 




Integrity concerns; foremost, (1) the correctness with which the 
program satisfies its requirements, implements fts specif ideations, and 
does nothing els'e. But integrity concerns^ more than correctness, ^It 
Blso relate^, to. (2) satisfying a trained user's expectations of 
program behavior and to (3) being useful in fulfilling .an intended 
mission. Furthermore, integrity requires that (4) the program can be 
eva4u^ted to establish a level of trust in .it. All four' ^aspects of 
integrity. must hold over the full life cycle of the 

System integrity is a function' of the integritynof the^program parts. 
Usually system integrity is lower than the integrity of- its component 
programs; however, if redundant independent modules are employed 'to- 
check one another's computation, system integrity can b^, somewhat 
higher than the integrity of the component prd^r^ms. ^ ' ^ 

In supmary, program integ[rity will require management ^td ' judge the 
risks' of adapting level of integrity for^ the given- threat 
environment. These factors in assessing pr<ygram integrity in the 
context of risk are expanded in the balance of this section. T+ie 
issues presented form a consensu^ of tite 'session participants. - 
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2. A CONTEXT FOR PROGRAM INTEGRITY 



1 



Security^ a computer System increased with a reduction ' in (1) 
system tlaws, (2) >exposure of system assets, and^(3) exploitVs. ATI 
protection strategies pursue these goals. Program integrity addresses 
only the first qoal— flaw reduction. • . - 

However, management can make choices in its protection strategy -to 
trade reductions in "integrity for improvement in the other -goals "to 
reach a balance for a gtVen threat or budget level. The issues 
associated with integrity are discussed below. • 

2.1 Prpgrams Ch"^nge With Time (Life Cycle) ) " 

We, normally thijft'-of , programs", *in their final ^code or operations 
stage. Program integrity, however, must be built into programs from 
the beginning of their development. Programs move through six stages. 

1-^ Organizatio n Mission : The. purpose ofVje system 'is'^efin^, 
• and responsibilities are divided ^mong the component 
; organizations. " ' . 

2. Requiremejits : Mission; re'sponsibi J i ties -are translated into 

, speCTfic system- requjj^ements; . i.e.^ what ' is to be done.*^ 
^ Functions, performance,' dost, and othefTimits are defined. - 

. . . • - ^' V 

3. Specifications : Requirenients . are translated into - system 
•specifications for each, svstem element— hardware, software, 

communications, people, facilities. Specifications defi^ie in 
detail _how requirements Will be met. Specifications exist at 
^ ^ the functional level and at the component' level. -For the 
software component, they ;are called "coding ^specs." Various 
schemes exist for documenting coding specs, including^ flow 
diagrams, decision tablets, table and memory layouts, 
mathematical algorithms, ' Parnas-Uke . modules, and most 
recently, formal specif i qc^ti oh languages; ' 1 ' 
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^2^- Specifkations. are translated into source code in some 
popular programming language,, e.g., , PASCAL,. PL/l,^ FORTRAN, 
COBOL,- or machine assembly language, ^nd further translated 
into run-time object code or micro-code by l^ngQaqe compiler 
or assembly tool's. • '- ' h ■ ^ ^ 



^ ^' i^Lla[ll,J.nte2Tation Befom, programs are placed 
^ production they are tested irfaividually and as part of 

total integrated- system. This step 'is performed in add 
to the normal ."unit" testing and "debugging" 
programmer of the original code. 

6. Operations and Maintenance (O&M) : Libraries of source and. 
-object co^e programs are stored for yse in the computer 
■ facility. From time to time, minor* ch^ges are made to these 
/programs. -by .the O&M staff to correct errors, improve^ 
, performanos, expand ftinctions and capabilities, or adapt to 
new, equipment. Control of ' these changes is part oof O&M 
••Configuration -Management. O&M can get out of hand, and 
program integrity can suffer, if major .program redesign or 
modification is attempted at this, stage. ' Major -program 
than^es must be viewed' as new software that will replace, 
. , existing modules, and these new wfodules should be" contracted 

for as were the.. original, program^, -beginning at . the ^^mission 
and requirements life-cycle sta'g,es. 

2.2 Visiblity of Relationships l^s Lost Betweer> Stages ' 

• ■i:!lf^°^ ^^'^^ significants program integrity problems that 

resu tSfrom this staging of ■ software production is Vhe loss -as 
complexity and detail; increase, of .visible link-s betwee/ the ^stages 
For example seldom is it possible to directly relate a module of code 
Dack to . the mission goal,^ or systepi requirement, or even the 
Tunc.tional specification. Somehow, the connection gets lost as 
functions are distributed,, level notations ar£ translated to 
lower- level languages,, and programs are 'made to serve multiole 
requiremerlts. ; , ' ' ' - ' . ; . lu i-ik-.c 

> ■ , ■ , *'<*.>'' 

ThMs loss of. the .Wead between .the initial requirement and the 
resulting .code becomes serious- whert code .must be changed for any ' 




purpose. The more significant, the modification, the greater is the 
need' for comprehending- the. interrelations of the parts toward 
satisfying the miss.ion requirements. ..Code patching is a major cause 
of integrity loss, for the "tactical" fix often undermines an. unseen 
"strategic" mission design, leadingto even larger problems. 



2.> Program Integrity Assessment is Multi-dimensional Problem 



Determining when to audit and evaluate in the life-cycle 
metamorphosis of a program is. but one dimension of the integrity 
assessment problem. Other dimensions include the relevance and 
severity Qf the security threat and the methods employed iJuring 
development to achieve integrity. These. dimensions are treated more 
fully in the following sections- 



3. RELEVANT THREATS AND THEIR .SEVERITY 



Threats result from nature and from man. The effects of natural 
disasters, physical . breakdown^ and human error (by builder or user) 
can be predicted in service interruption or , accidental information 
disclosure. More insidious are, the threats from motivated human 
interlopers. We further divide the ,human threat into casual and 
deliberate attacks. The former* group deals with individuals who 
stumt5<le on a flaw or actively browse and seek flaws they can exploit. 
The latter group is jnore sop/iisticated uT^reiources , planning, and 
methods of attack. These de/liberate attack threats are carefully 
planned by a conspiracy team that creates flaws by modifying running 
code or planting ■ subversive "trapdoor" functions in the system;, 
application, or' library pr'o'grams. "Possibly the worst deliberate 
threat is from an irrational attack by a disgruntled employee. Since 
the normal behavior^ constra^ints on the attacjcer ~ exposure and 
capture or expectation of gain — are .Absent or distorted,' the 
irrational attack cannot be thwarted by most countermeasures . 

■ . •■ . .; ■ ■ . ■ ■ -f 

Ranking these threats by the severity of the attack and so^histicali&rt. 

of the needed countermeasurjes , (high-to-low), produce the followirta 
I T<;t - . ' ' • «). 



1; IRRATIONAL ATTACK 
Z: CONSPIRACY TEAM 

3. BROWSER 

4. STUMBLER 

5. -HUMAN ERROR 

6,. NATURAL FAILURE' 



4. METHODS FOR ACHIEVING PROGRAM INTEGRITY 



It w^s established by, consensus of the session that program 
integrity requires the . program to be^ correct, robust, and 
trustworthy^. A correct program provides. evidencF'tfTat • TF'Tatisf ies* 
Its missipn, requirements, and specifications. By analogy to the 
auditing of a corporation, the audit of a program's .'correctness 
requires evidence equivalent to the -corporation's ^'fi^nancial 
statement. . . , * 



•'A robust-program includes m^echanisms^'o ' maintain adequate levels of 
performance -in the face of unexpected behavior in the environment, as 
will occur from user keystroke or prcfcedyral program flaws,- operator 
?u m'- tH' • corporate audit analog for these robust mechanisms is 
the intejPoal financial controt sptem." 



A trustworthy program is one that is well 
complex, modular, "relatively shori - in 
rigorousljj^ structural architecture, and p 
programmiing practices' and senstbie^tanda 
programs ' is the corporate analog of 
accountirfg princi.ples'." 



4.1 Evidfence of Correctness 



documented, functionally, not 
lenqU^, integrated into a 
as the result of good 
The ' trustworthiness of 
fciving "generally accepted 

•t 




Program validation and' verifi cation (V&V) can be either static 
(done on the source code) or dynamic (done' on the running object 
oodej; I' 
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4.1.1 Static Evaluati 



on 



Combinations , of the following source code examination approaches * 
are currently being used by -industry or R&D laboratories: 

1- Des.i3n Rev[ew: -This method 'entail.s a formal meeting of-" 
designers with reviewers (not associ-ated with. the - 
deliverable) to scrutinize the f)roduct design against mission' 
and requirements. The product d'esign should include 
narrative .documents, logic diagrams-, and functional "and 
coding specifications. It may include sourte code f.or 
critical, components. Resign Reviews shoujd be scheduled 
milestones for each subsystem- and major ' component. Results 
'must be documented and comrftunicated to» alV participants. 

■ Peer Review: The classical scientific method ,V§ to invite 

•interested professional peer review and comment on" the " 
^ product at -various stajes of , program life, cycle.- Design 

. , reviev/ is one importalif Instance of -peer review. 

-Quality Control (qC): A third party /(neither customer- nor 
developer) is committed to check 'the , quality of '-all 
deliverables during product- ijife' cycle. This- technique 
com&ineSj I and 2 aboye ' in a forgial, .often "contractual 
manner. Th'e QC contractor is. 'selected because of ' its 
exper^-ence, -tools, per*sonneT, and .skill in such work. ^ 

■ \ . • • 

^- Compllen Checkinc]: Source-cocfe-to-pbject-code ti^anslators 
(1.. e:, compilers) have always been ' u^sed to detect program 
errors as a'QC tool. R&D has st|ggeste,d new dnphasis on ' this ' 
. technique as a mechanism ,fon enfoj-cirtg 'good - programming 
practice. .New languages demand.,' explicit, detailed 
declarations of a" programmer -intpnt with>. strong data 
typing, > restricted program scopes, ■ rigid module -calling- 
sequences, etc., that force ^structWed pvogramming.' The> 
compiler's for' these - languages do textensive and complet^ 
checking to enforce the. language synta'x and semantics, and in 
some cases generate code for -run-time , enforcement of,* program 
assertions . » , * 
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6. Automated Analyzers: A number of sout*ce-co'de tools . are 
available that perform some of the syr^tax. and sema'ntic 
analysis of a compiler,, but do -not generate' object code 
,^ Such tools are used to produce flow diagrams, reformat" c6de 
^ " -to aid dqcumentatioTij produce" cross-reference listings and 
. indices'for improved library control and Ose,.and to* produce 
Vtest cases for dynamic evaluation. Newer" uses' are to 
automat-ically gene/ate'truth assertions about" the.' program to 
assist in the fomra-1 proof of correctness. 



- -A. ^bvmY;^^^^_LjLjomB.'\ proof of program correctness- is the 
, _ leading edge of the state-of-We-art. Basically, the method 
accepts "correctness criteria" and the ."program" as input, and 
produces as output a fomia*l proof''5(or 'counter example) that 
, N^e program satisfies the correctness criteria. In practipe, 
th^ technique Js iterative at, each 1 if e- cycle stage. Ab the 
top level, the correctness criteria are "a set of truth 
. assertions and n>athemati(^al models of Vpsrafii requirements, 
-and the program-'is a mathepiatical 'specification,' boih' 
expressed • in .a "specification language." ./At the lowest 
level/ the correctness. crite,i*i a are the prlor'^'Hevel 's output 
specifications, and the program is the Higher .Order Language 
(HOL) source code. At each level, these inputs— criteria , and' 
prografn— .are -processed through a "Verification Condition 
Generator.," which .produces a set- of conditions to be' 
verified. "The "verification condition?-," e.g., " source 
program and trxith assertions, are processed by a "Theorem 
Prover". producing a formal mathematical proof ' of 
correctness-- i.-e.» a proof that the sourc.e program satisfies 
; . the truth assertions. . The process caii ' be manua-1 or 
autont^tecf. 'A- number of quite restricted "programs" have been 
. proved both manually and with autonfiated ? aids, leading to' 
■ "Encouraging optimism.. However, the problems are great, and 
not fUlly understood^ the progress controversial ' "and slow, 
and the tools limited and not commercially iavailabl'e. h'' - 
i • i 

r . ^ 

4.1,. 2 Dynamic; Evaluation / / ' 

- - » - , ■' 

.'. ■ • ' , ■ 

Essentially, this approach '"runs the program' and "sees if it' 
works." - Unlike static evaliiation, dynamic evaluation- also tests "for 
errors vntrodueed by the cfompiler, loader, 'ope rat-in g system^ libraries 

) ' / ' ■ . ' ) ^ 
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, and support packages, pl^ysical procedures, copunication elements', and 
CPU -hardware. Static evaluation tries to exhaust, all program 
conditions; dynamic execution involves real time and is practi,cal only 
for selected test cases. Therein lies the basic "art" of testing, 
•that is, choosing the best test caSes. Many ^schemes' exist. The 
Department of Defense (DOD) testing requires three stages: (1) unit- 
testing of discrete modules; (2) subsystem testing of "the integrated 
collection of mA'bules; and (3) system testing of the. -integrated 
collection of subsystems, actual hardware, and real -data. This is. a 
reasonab|^e paradigm for other approaches.* 

♦ 

4.2 Evidence of Robustness. • 

/ . . • . ^ 

Unlike correctness, little formal theory exists^ regarding 
robustness mechanisms. The best that can be achieved today 'is to list 
tho^ methods that have provert effective in existing systems. 



4.2.1 On-Going- Testing 

• r ^ " ' ^ 

Testing should not end after' system^ delivery, and O&M commences. 
A number ^of^ schemes have been suctessful. *^ » 

^* ^' Exercising : The system is tested by rTnning sifijulated 
operations with known responses that are compared against 
test results. This is a well known approach in tq^sting ^DOD 
systems in the field. A- modified version , has, seen recent 
^application in the commercial sector, where a simulated 
^ minicomiJany is established in a corporation's, financial 
^control system so *that the auditor can easily, ^observe the 
system' s*sresponise to test input to' the mini company. The^ 
\mini company approach it also knov/n as the Integrated Test 
Faci lity ;(ITF);tilethod.. . ^ \ . 

2. Flaw H yp6thesis Method" : '^In this approach, system, flaws are 
; , ^ hypbthestzed bas^d onah^logousL flaws found in*o^t^er systems, 
and are tested for existence on the object system. It is' a 
cost-effective approach to test case selection, 

■ ■ • i ' \^ ■ ■ 



• ^- Surprise Test : Ba^ed on the milftary Jnspector - General- 
'Scheme, the test team arrives unannounced runs tests on 
the live system. Such schemes exercise ^he current Jive 
system and unpover possible unauthorized versions or modified 
operating procedures. 

'^4. Reas onableness Checks :. The system is - tested "^n its ability 
to detect and recover ^ from typical huirfen errors *such^ "as. 
typographical errors/ out-of-context .actions, nonsense 
c6mmSnds (e.g., rewind card reader), etc. 

*■ * ' * ' ~ ' 

5. Error R^overy: The ,sykem" "is te^ed * on its. abilrty^ to 
detect ;| ancT]^ recover .if 1:0m a variety of - hardware, 
communic-atioris, power interruptions and surges, and program 
errors. Of particular interest is restart, theck point, i>rfd 
roll-back options* " . \ > • ^ 

4.2.2. ()n-Line Monitoring and Control . 

, '* ' ■- • ■ ' . - . • ■ 

One class of jS'S^jce found useful in DOO , app-lications invalves 
on-line control -bl', a. System Security Officer (SSO). The SS6* is 
concerned -with misuse or subversion of the system^ To assist in the 
detection of thesb and other breaches of system integrity, the SSO,. has 
control of 'tjuilt-in surveillajice, ^monitoring, subverter, and. 
journal ing software. ' These programs "permit the SSO to test the* 
environment of the system to ensure, proper v«)rking order, to , log 
current activity, and" to ' investigate individual exception cases. Tjie 
concepts, apply .to systems integrity in general, beyond the\ DOC) 
national security concern. Of particular conqern^ is the management of 
the System secuVity, data ■ base', of slibjec't clearances, object 
'class,ificationSj ; encryption keys, user identifiers (IDs), , and 
passwords . : ' ■ ; » ' , • , / 

4.2^3 - Redundancy ; , , . , 5 ' 

■ ■ ^ i . , ^ ) 

; A popular hardware approach to integrity hpis now found limited 
application in software. If- multiple different ^al'Qorithis exist for- 
computing a result, these can be compute4 redundantly by different, < 



independent modules, as par.t of tjie . operational software, and the 
results can be compared and -exceptions reported (possibly to^the'sSO), , 

% 

4.2.4 Support j::^trol^ , • " ' 

Confidence^ the 'system's robust behavior can "be attributei^ to 
the facility management and O&M prqcedures. .theie fajl into thr^e 



areas: 



1; Code Control : Good program* libraries are required to permit 
seTective access to system and * user code, and , to permit 

" . rationarl change procedures for error correction an^ software 
upgrades. ' - * ^ ^ 



^' ^^^o^_ Control: Errors will, occur - and v/il3 need to be 
. reported," and "appropriate actions wi^ll need to be taken. 

- Documen tation Control : Source pi^gram libraf^ies are one^ form' 

of documents'; CTser and system manuals, ^and 'other fqrms of 

English documentation' must -^be kept' current to the: level "^f 

the software in use if errors are not to be' introduced by 
datjsd descriptions and procedures. ^ • 



4.3 EvicJence of Jru$tv/orthine€s 



Tpfefsted software is obtained from a successful blend of factors: 
(1) experienced personnel,^ (2) organised software development, and- (3) 
gbod tools. Each of these factors may be developed in a ' variety' of 

4.3;r People. ' ' ' ^ ^ , - 

Skilled people can be'as much as. twenty times more effective 'thahl 
less skilled people fn the quaiity . of code they produce- 
Tv-ustworthiness of code is ioiprove^ by demonstrating good personnel » 
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- ~ salection ^nd training practices, and by personnel ^ experience. The 
OOD employs a system of t)ackground investigations" to screen personnel 
,f(sr suitability to various levels of job sertlitfvity. . 

4.3.? Software Development > 

.One trusts better-made programs. ~ Sincg a software product 
mirrors -its production management, better- production method's yield 
better products. This suggests a trustworthiness evaluation method. 
I.e., scrutiny of development practices yields' insight into" product 
trustworthiness. The following^ .steps can be taken to' perform a-^ 
•comprehensive review of the programming practices emp-loyed: t 

• Assess the standards, quality control methods, and management- 

• ^ ^ controls employed. Are'they well docCtiWented, read, and; used? 

2. Explore methods, used to make producti-on ' status visible to 
management. Are the data mean.ingful? 

^ - . \ ^" ' : 

■ 3. Detennlne the degree^ of autqmation em[>loyed to enforce'^- stated 
management and programming practices. ' , :y 

4. Use an audit team to exam^ine the programs in depth for 
' ' compliance with ^stated management and programming practices 

Are they well documented? ^ , 

5,. Examine procedures' and history of corrective aci;;ion lo 

problems detected, in prior audits, ^reviews, ".and tests.\. Was 

meaningful action taken to rectify problems and did 
' ' production improve?!, ■ ' ^' 

■ • ■ • ^ ■ ' •■ ■•. ■ ■ • 

Good tools amplify .skills and can aid all aspects of trust 
evaluation, by gjving confiderlce ,in the quality, "tinfeliness, and 
cohtro.l of^pr'ogram development. Among the tools of significance, are: 



Production Tools : LanguaTge preprocessors and compilers, test 
■ -case generators, program production ' libraries,, proo^ 
verifiers, theorem provers, assertion gen"^rators. 

2. Management Tools: Configuration controls, status monitors, 
'Standard?; Equality control procedures, error and ' change 
controls, co'st controls, mpdule- to-mission linkage threads. 



^' Documentation Tools : Flow charters, word processors, 
" ^ document li Br aries, and change controls. 

^- A udit Tools :' Fl.aw 1 ists, ' penetrations analyses, test cases, 
flow charters, and redundant but independent production tools 
to test rpeatability (e.g., 'compile a randomly selected 
module with the audit compiler and test the object • code' 
produced by substituting it in the system). . . 



5.0 PROGRAM INTEGRITY IMPAGJS OTHER SESSIONS* 



Our broad interpretation of program integrity (s a 
multi-dimensional problem im|a,cts the discussions of other workshop 
sessions. We summarize thes^ considerations for each session below -' 

• ''5: ^ . ' " ■ - ' 

5.1 Internal Audit Standard 



It IS . imperative that internal audit standards reflect • the 
guidance presented in this sessiorp^ Of particular concern is our 
recommendation for agencies -to perform self assessment (cf • 6 3 
Recommendations).^^ 'f • ^. . 

<^ . \ - - . ^ ^ ' 

5.2 Qualifications and Training 

-Sitfic^program integrity is a complex technical subject audi tors 
need to dffaw upon independent, , experienced, competent, professional, 
and technical computer science talent. . ' ^ 
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5.3 Security Administration • I 



One area often overlooked is the management of system control 
data, upon which program integrity is dependent. This -must fall to 
security administration, possibly \r\ the form of a. System Security 
Officer, (SSO). Data- included in' this is described in paragraph 
4:2.2, On-Line Motiifortng and Control. Furthermore, much of our 
discussion in Section 4.2, Evidence of Robustness, is pertinent -to 
security administration.- 



6.4 Audit Considerations In Various Sys^m Environments * 

We feeUthat program integrity consents herein apply to all 

software,^ regardless of application, including' distributed systems, 

communications processors and smart terminals^' controllers, and 
microcode. ^ 



5.5 Administrative and Physical Corltrols 

TheMWhole facility management mechanism fbr controlling access 
and changes .to software stored off-line* is a cornerstone of trusted 
software. Furthermore, the issues of the on-lipe System Security 
Officer and remediaV actions for backup and recovery impact physical 
controls. We also point out that system integrity can often be . 
raaintaine^ at an acceptable ri«k level even with flawed programs, by 
increasing , physical access controls -to reduce the exploiter 
population. This does not preclude natural failure and human error. 

.^5.6 Program Integrity • ' ' . 

^ • . . • ■ 

^Not applicable*. ^ ' ' . ^> 

•5.7 Dat^'a integrity > " - . . . 

■ /'-;...• ■ . . ' 

j By defini-tion, data integrity does not impact program integrity 
;since system control data is tonsidered part of program integrity. On 
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the other hand, data integrity cannot exist without program 
integrity. Where existing software .of dub4qus integrity is employed, 
caution is in order, and steps should be taken ,to reduce "the risKs 
(cf. 6.1 RecommeYidations) . /. ' . 

* V 

/ 

5.-8 Communications 

See pa^agraph 5.4. above » ^ * ^ 

5.9 Post-Processing Audit Tools and Techniques 

All of Section 4, Methods Vor Achieving - Program Integrity, is 
relevant. 

5.10 Interactive Audit Tools and Techniques 

A^l of 3ect.ion .4, -Methods for Achieving Program ' integrity, is 
relevant; \ . 

6*0 -RECOMMENDATIONS 



The following consensus recommendattons are' made regarding the' 
audit and evaTuation of program 'integrity: 

6.1 Existing Software / 

0 Be cautious nn assuming program integrity, especially witb' 
sensitive applications. . ^ \ ^ ' . . 

0 Although limited, tools 'and techniques /for ^auditing and^ 
evaluating ^program integrity do ^exist. They shoul'd be 
app^lied via a^ careful risk management analysis. 
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0 Reduce the effect cxf the lack of program integrity by 
improving physical-,- procedural, and management control, 'and 
« upgrade the O&M organization. 

* " * * * 

0 Reduce the exploiter population by access controls and user 
authorization screening. 



0 Reduce the asset exposure by removing the asset from the 
system wIfen it is not in use. Encryption may be used to 
•accomplish the sarr^ effect. 

Future Softv?are . 



0 Improve the production process with rigoKous enf or/cement of 
good programming practices throughout the program's KuJl li 
cycle. 

0 Assure .program integrit/lrompl i ance at each development^tage 
from mission objectives, functional requirements^ system 
specification, HOL code, and O&M. ' / 

Organization Actions 



Each organization must do a self-assessment of its threats' 
and involvement in the life cycle of the programs it uses 
The earlier the involvement, "the better, depending on the 
degree^^of concern for security threats. ^ - 

Organizations should prepare detailed guidelines for 
development or acquisition of existing- and future' software, 
with consideration given to the . auditability of program 
integrity. 
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EDITORS' NOTE 

A brief biography of the Session Chjiirperson .follows: 

^ .Mr. Leonard I. Krauss is a Manager, Management Consulting Services,- 
in the New' York- off ice of Ernst & Ernst where he is a consultant td- . 
management , 'in the areas o"f planning and control systems, data processing 
management, frand information system security. His system planning and 
development^^experience includes a variety of computer applications for 
financial ih|tttutipris, manufacturers,, service companies, and other 
organizations. Mr/ Krauss was previously associated w^ith IBM' and 
*Unipn Carb-ide. H&~has also been^an officer and direc-tor of several . 
companies and held positions s^s Director of Management Systems and 
*.8asoject Manager for Advanced Management Systems. A 'registered profes- 
sional industrial engineer, he has earned the CDP (Certification in Data 
Processing) and is the author of three popular books: tomputer-Based 
Management Information Systems , Administering and Controlling the 
Company Data Processing Function , and SAFE: Security ^Audit andTield 
Evaluation for Computer Facilities and Information Sy^stems . ^He holds a 
MBA in Business Management Systems from Fairleigh Dickinson University 
aiJid a BS in Industrial- Engineering from Pennsylvania State University. 
Mr. Krauss is a frequent speaker at international management^ confer^ences 



The charge given to this session was: 



DATA INTEGI^ITY: What are the audit approaches and techniques for 
: evaluation, of data integrity in an.ADP environment? ' ' 

Data integr^ity Is the state that exists when computerized data, isvthe 
same as that in the source documerttation alid^has not b^n exposed to 
accidental alteraCtjon or destruction- It includes -both data'accuracy 
and data protection* Computer generated, data involved in automatic de- 
cision making process should also be considered. 

/DatA integrity is an area that has traditionally beien addressed by th^ 
^ audit community. This , session- is to identify those audit approachesWd 
'techniques*'that are unique to an ADP environment and have not been su^ 
jected to e^^tensive coverage in the literature. * , ' . 



The consensus report^ that follows was reviewed by the entire membership 
of this group. It was written by. L. .1. Krauss and S. W. Katzke. 



ERLC 



9-2 



9 



Dat^ Integrity Auditing: . y 
A Framework for Standards* Development- ' 

• 1. INTRODUCTION , 

' ' • •• » 

•fh«. cf"/"'^^I and. evaluation of ADP security calls for an examinatien of- 
the system of safeguards used to prevent; deter, detect; and limit the 
impact of undesirable events. 

^" adequate system of safeguards is one having' design, implementa- 
tion, and compliance characteristics appropriate to the magnitude of the 
ri-sks and exposures assoicated with undesirable events". Examples of 
undesirable events include: >an ADP center file, an unauthorized updat^ 
to data tjase records, and an- illegal tap on a data communications line. . 
Examples of exposures include: destruction of assets, erroneous dis- 
bursement of funjds, embezzlement and fraud, disclosure of personal or 
proprietary information, pol itical/mil itary/competitiva disadvantage, 
faulty decisions, extra operating expense, legal and contractuaJ 
penalties, interruption of- critical ADP services, and loss-o'f Iff^. 

*. ,-n J" auditing and evaluating the system 'of safeguards for ADP, 'there 
?nIL f^^ve either a direct or 'an indirect bearing on data 

integrity. The audit an d 'evaluation of data integr ity safeguards, for 
purposes of thiTreport. is limit ed to factors having a direct beari ng 
agdjvhig h pertain to a parti cular ADP application selec ted for Pxamin- 

ation (data ingegrity audits are conducted on an aopl ication-by- 

application basis). - n. • T "J' 

,-n,^iMH!^*?'"^-'*^f4|i^^^^ ^" intlirect bearing, for purposes i)f this report, 
include physicalf^operatidnal,. administ'rative, and software security, W 
measures which are part of the fiio,re generat system of safeguards and ^ 
which are not usually pecu-li'ar to any one ADP appMcaJion. These 
general security measures.^are recognized as being vitally, important-so 
much so ^hat It may be virtually impossible to have "adequate data 
integrity safeguards for an ADP application in an environment v^ere. 
there ar.e s\5nifi,cant inadequacies in the system of general safeguards. 

• Inadequacies in the system of data integrity safeguards are some- 
times indicative of weaknesses ,in the general security system, in much 
the same w^y that abnormalities in a person's blood pressure and cell 
counts indicate a malfunction in some other part of the body The 
auditor m6st b,e alert to such possfbilities and point them out, even • 
though the scope of the data integrity examination does opt encompass 
a detailed study of them. • « ' , . 

. Spec^ically,'a data integrity,, audft must evaluate the policies aWd 
procedures th^irectly -affect the ouality of all forms of data (e.g.\ 
source, entry .^ocessed, and outpt/t) in" the application system under 
review; As a prerequisite to a tiata Integrity audit, the auditor 
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must have a clear understanding- of the definition of data integrity and, 
the objective and scope of the audit. To perform the audit, the auditor 
must first formulate an approach or work plan and then use appropriate 
and acceptable methods for conduqting the audit. During the course of 
the audit, it is necessary that the definition of data integrity and the 
objective ^of the audi't always be kept in mind. 

Section 2 provides a definition of data integrity Subsequent 
sections'^discuss the objectives, scope, ^approach and methods for con- 
ducting the data integrity audit. • * * 

2. pEFINITION OF DATA INTEGRITY 

•• • ■ • \ 

Data integrity is the state that dxists when data are (within 
defined limits of reliability) accurate, consistent, _ authorized, valid, 
complete, unambiguous, and processed according to specifications in a. 
timely manner. It is important that this defi^nition be. constantly 
referred to during the course of a d^ta integrity audit. 

, , 3. OBJECTIVE OF THE 5ATA INTEGRITY AUDIT 

fCeeping the> definition of data integrity in mind, the objective of 
a data integrity audit of a particular application csystem is to rerfaer 
an objective opinion ba^ed op an evaluation by qualified individual U) 
as to the: 

(1) Compliance with existing, pol icies and procedures for 
m aintj miing data integrity ' ^ ] ^ 

' . (2) Adequacy p-f the existing policies^and procedures ^ 

In addition,' as ^a^result of the compliance and adequacy evaluations » 
corrective actions may be re'commended ti^nhance the' data inte^grity of 
tMe application! ,systetf. Furthermore, it is essential that the Sate the 
audit is completed be recorded since it represents^ specific reference 
point. Arty assumptions about the state^ of the, system* s, data *integr^*ty 
made after this date become less and less valid as time goes -on. 

When condutting the data integrity audit, »it 'is important that the 
bjective of^the audit be kept in mind. ' , . . ^ 

4. SCOPE OF THE DATA INTEGRITY- AUDIT • ^ / 

The scope of the data integrity audit is necessarily broad since 
data associated with an application system ^xist in many forms and are 
affected by policies and procedures in differeni parts o,f the system and 
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in the organization which prp,v4des and uses the "data. However, it is 
m% generally practical to t^ve :a data Integrity audit include examin- 
ations of all related system areas that affect data integrity. Among the 
functions that should be included 'as part of other audit pro cedures would 
be verifications of: •» . / : ' 

0 Underlying physkal .facts represented by data elements 

(e.g.-, counts, jzionfirmati on, observations) 
0- Software integrity and software maintenance controls 
0 Physical, administrative, and operational security 

Vu J? achieve the previously stated objective of a data irttegrity audit, 
.the following areas should be evaluated with respect to 'compliance and 
adequacy of existing policies and procedures and .approp^iate recommenda- - 
tions should be made when they Vill improve data integrity. 



for aniauto- 



Rel labilit y of the Data Source^ The sources, of "data ror an;a 
mated application system will vary according to the applicijtion. 
They may range from data collected manually to data collected by 
automated data capture devices such as automatic .tel ler machines 
and point-of-sale-terminals. In some cases, source data may be 
transmitted to the application system by feeder s/stems. 

Whatever the collection method, it must be shown that the sources 
are reliable ones. This requires the atiditor to verify that^a 
particular soui^ce of data is the designated and authorized on^,' 
that the data obtained i$ current and timely, that the data is 
captured as 'close to the source as practical, and that adequate 
separation of duties ^"sts betwfeen the Creation/collection and^ 
the authorization of source data. ' ^ . 

So urce Data ^.reparation . Once captured, raw source data must, in 
most cases, be prepared, for entry -into the ADP system." -Data prep- 
aration requires the conver'sion of raw data, in some instances 
using a codification scheme, and transcri|t-ion of ^he converted" 
data on. to additional, source documents. Fo Mowing c(5nversion and> 
transcription, the.il^ta may be further converted to a machine- 
readable fortn (e.g., keypunching) prior to entry into .the ADP 
system. In situatioftsj^re the source data is collected in 
automated form or is keyed in directly to an on-line system, the - 
data, preparation function may be minimal. Data preparation is 
highly susceptible. to hyman errdi^. Furthermore j;44:^is» a likely 
place ^or the insertion and manipulation of recordsfor fraudulent 
purposes. . > " . ' • • - - 



To. evaluate 
review the 
tion proce 
at^ contrb „ 
con^letenes 




ource data preparation controls, it is necessary tol- 
■a- preparation policie's?. as "wel 1 as .the ^ata 'prepara- 
^ and training programs.- The existancje of appropri- 
'"'ords for determiniag accuracy, alithorization, and 
source data records should.be verified. Aaditfon- 



ally,, data codification structures, should be reviewed to assure 
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rons^^tency between data briginalnng from diffajrisnt sources or 
spurcje d^umenfs'and toi as^surVacffiuracy duMng conversion. 



Data .Entry Control . Methoqs-^for entering data^ into the ADP systen^ 
wiTKvai^ widely from applicai^ion to application^ In some, systems 
dat^^rap^ure and entry take pfcfce 'simultaneously through devices 
siftfn as ajjtomatic teller" machines, point-oftsale' equipment, and 
optical character readers. In others, keying of .data may take -* 
place on-line, or in key-to-tape and key-to-disk devjces. In some 
causes, data may enter the application system -through other systems. 
Like data pireparation, data entry is high.ly error-prone. It is' aljso 
a likely place for the insertion and manipulation of records for ' 
fraudulent purposes. Whenever possible, detection and correction 
procedures should be used to prevent erroneous data friDm entering 
and corrupting the ADP system. 

To evaluate the data entry control procedures, the auditor should 
fir^st review the procedures being utilized, including criteria for 
accuracy, completeness, and authorization. Traininf^ programs and 
plans should be* reviewed as well as instructions for data^ntry 
that are given to data entry personnel. It is mandatory t^ review 
the error detection and^correction procedures and tQ determine ff 
they are adhered to. * , 

Data Input Acceptance Control . Input data (transactioqt , master' 
file and data bas,e^maintenance, tables, etc.}- can pass_ through 
"Several Organizational areas as source data is captured, prepared,! 
and enterfed into the, ADP system. In some cases, data enters the ADR 
sys.tem through feeder, systems from distributed computational points 
of the organization or from outside sources. When the custody of 
input data changes hands,, u0 to and'^ncluding the point where it is 
entered into the appl^ation system^, th^re should be data input 
acceptance control procedures which define accountability for access, 
authentication, and accuracy of the input data. 

As part of a data integrity audit, itjs essential that input data « 
acceptance cpntrol procedures be evaluated at each control^ point 
where the input data changes haijds.. This evaluatfion should include 
a review of input data acceptance control prodecures for the purpose^^ 
of accountability and a review- pf input data access and authentica- 
. tion controls. In adctiti#n, the existance of appropriate control 
recorHs for determining the accuracy ar)d completeness of input data 



records sliould be verified 




Data Valtdation and Error Cgrrection . Prior to. the use of input 
data in an ADP system, the^^ta should be jcarefully validated 



(i.e., fedited, checked) to detect erroneous data. If errors are / 
^found,' tTiey should be corrected and reentered into the system. 
Thus-, when 'conductirtg a data integrity audit, it is necessary^ to. - 
evalu^ite the da^flT validation and error correcl:ion procedures. This 
includes a tli(orx)ugh review of existing, procedures— including 
recommendations for corrective action when nfecessSry. In- cases ^ 
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wher| manual procedures for data validation have been replaced by 
.automated controls /'-the automated controls should be reviewed to ^ 
assure they perfonfti the intended :val idation functions. Finally, 
contrors for hanjMing erro^ rejects, corrections and data reentry 
should be reviewed. " « . , 

Processing Specifications . A key factor- affecting the dalia integrity 
of an ap^jlication system.;js ihe assurance that data is processed in 
accordance with specified formulas or rules. Ideally, these 'pro- 
cessing specifications should be formalized arid recorded with the 
system documentatiwi. Often Jh^se specifications are informal, not 
■ recorded in any form of documentation , ^and are known only by a few 
individuals. In some cases,' -'the processing specif ic-ations may 
exist in a combination of states.' s 

Whatevemhe form of the process'ing specifications, they must be 
evaluated^s^ paVt of the data integrity audit. This evaluation 
should include the review of all processing specifications and the 
review of processing controls both within the ADP system and between 
the system components that, can affect the processing. It would 
cover controi^, procedures, and safeguards ?uch as those pertaining 
to procfi^^^ of proper files, internally* generated data, program 
sequence", privacy transformations, and access (user identification/ 
authentication/authorization). In addition, backup, recovery, and 
restart procedures should be reviewed as part of an evaluation of 
the processing specification o^ an application system. 

Keep in mind that a secure, data system "operates without surpri^esj^ 
meaning that it behaves as intended and according jto specifications, 
fails according to specifications^ and gives *a predictable response' 
when it is functionijig' as expected as well as^^wKen, it is failing. 

- Output Controls and .D4sJ;ribution Procedures . The ciccuca9y/ 
reliability and tim^ness of cbmputerized output ahd the access to 
and distributiorv of fthe output to authorized individuals are factors 
affecting data inte^ty. As part of a data integrity audit, the 
internal (i.e-. , autort^ed) controls that ensure the quality of ^ 
output reports and generate.d magnetic media should be evaluated, 
as shoul'd the access and distribution procedures for the qutput. 
In addition, output forms control^procedures* should (be reviewed. • 

'* 

Auditability . ^ The ability to meet the objectives of a data integrity 
audit depends/ to a' large degree, on the auditabiltty of the appli- 
cati'on system under review. Auditability requires that procedures 
and, policies are in place to assure that the information and docu- 
mentation neq^sary to perform the , data integrity audit is-availa- . 
ble^. timely and adequate, ".hus, assart of a data integrity audit, 
the autiitabi.lity of the ADI^ system should be evaluated. ; 

This evaluation siiould include a review of the quality and quantity 
of data retained for auditing, backup, and recovery purposes, a 
review of -the length^of time thatf^ such is retained, and a review' 
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of the^TUTTency and completeness^f the system documen-ta^tion/ In 
addition, an audit trail raechanism"^+iQuld exist and^Yts documentation 
-should be current and complete. In general, an .evaitotion of audit- 
ability, should include a review of policies and procedures for 
maintaining information that supports audit objectives. 
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DATA INTEGRITY AUDIT 



The' success or a data integrity audit deperi^ds .upon the thorough form- 
ulation of an^approach or >vork Rlan for auditing\the application system. 
During the development of the work plan, itjs important to keep in focus 
the definition of data integrity; and the objective and scope of a data 
integrity audit. * With these in mind, the formulation of^a work plan 
should include- the following steps: , - 

0 Obtain^an understanding of'the organizatioris,;:^licies, procedures 
^■^ and practices pertaining to the application sj^steip under review. 

.—^0 Obtain a general understanding of the application system,, incl ud- 
-ing factors such as the intended purpose or function, the require- 
ments of the user community, the source and flow of input data, , 
the , processing requirements, the outpulurequirements and relevant 
time con§:traints., . 



I Identify specific data liiles, inpufe^^ processing steps, interfaces 
with other applications c|nd outputs which are utilized throughout 
the application. , ' . 

I Identify specific' control I'eatures or points that affect data 
integrity. . * , . 

s Identify potential threats to data integrity for emphasis when 
reviewing the application. ^ ^ 

^ Decide upoh the^ methodology (i.e., audit tools a^d methods) that^ 
'^will be used when conduct^ing the audi)t/ ' , . 

% ■ ■* r ' , 

Obtain an understanding of the human factors that affect the appli 
^ cation system,, jn^ludihg the human engineering aspects of the 
user interface/^^well: as personnel areas such as hiring and 
termination practices, emplqyee, moral , vacation and job rotation. 

Obtain an understandjjig of the hardware-, software and systems 
technologies, use-d in. the .application system. < \ ^ 

Obtain an understanding of the training .and continuing education- 
P^gC^ms^ offered by" the- organization. \ 

Obtain am understanding of the' application system's deveTofiment, 
implemeniati on^^and'-mai ntehante 'controls . . ^ . • 

Decide on the form of reporting the findings, conclusions, .and 
rrecommendatiohs of^the audit. • . ^ ' ^ ^ 

1?; 
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° ?.rl^ °? review .procedures for the audit that will assure high 
•techmcal quality of the audit. ^ ( ■ - ^ 

^ \ 0 Beci(J^ on audit staffing and project control methods. / 

^ .Once the objective, scope, approach and work plan for a data ■ " 
^ TlZTt r,all°l'M'lT ^PPl^'"^^-^ system'have bee established, ' 
Followfn'S tt lL^f IW'lf "''"3 appropriate audit tool.s and methods, 
hollowing the =audit, a^aft. report Of findings, conclusions and ■ 
recommendations shoulcTbe, prepared by th^ auditors, reviewed with ■ 
: appropriate management personnel, and submitted ,in firtal form If 
-• -^ornn -M "^^'"1:^5 have been recommended, the. managers ultimately 

' rl^a?3?ng^^l5;f ^!t] '° ''''''''' 

^1 M^H^5- FOR DATA feEGRITY AUDITING ' 

In conducting the aud'it, a variety of audit tools and .methods*" may 
be-^used to determine the, compliance with and adequacy of the policies 

procedures intended to insure data integrity in the application 
system under r6\?iew. Examples are discussed belowf • a ■ 

° Confirmation with users, customers, vendofs^or others- familiar 
- ! enough, with the data to assurje its accuracy,, completeness, -and - .5: 

^ cons'istency. (Except as a spot-checking technique, confirmation 
would be p*rt of other auditing procedures". However, the results 
of a data integrity audit show-Id be careful.ly considered- in 
decidiilg the objectives and scope of auditing through confirmation.) 

"0 Sampling techrrique^ whprp p'ortaons of 'the data population 

usually randomly selected items, are inspected to determine 

tne state of the data. Discovery sampling is intended to ' 

"S^n^ll K^^'Tr'^ °l ^^e- Additional 

samples may be taken and estimation sampling applied to them 

I Es^iniation sampling is used t9 determine the extent of erronous - • 

data in a data base by. applying statistical techniques to a 

, ' sample of the data for the pi/rpose of predicting the amount of 

.contamination. Attribute sampl tng may be ^^d to seVect records 

/ based on inconsistencies in characteristics within the record 

Itself (for exampl.e, ^n accounts receivable balance that exceeds 

the cre^at limit by 10 perceat or-more). It may also be used to 

test a population for the pj^esence of .particular; characteristics. 



,*0\/er 25 audit techniques are discusS^ed in Audit Practices reoort 

■V'XI^^ in^tftute. of .Inte rna I Auditors Au Se 

?hT$?rV. T-"*' ?l^-Vi-J.^'' °^ ^^^'o^-ts resulting from 

the SAC (Systems Auditability and Control) Study. 
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0 Parallel processing checks ^for cojrrect/processing of data by the 
application^ system. With' this technique, data processed by the 
, application system would be processed by an independent program 
performing the 'same^^f unctions. *The two results would then be 
i ' comprared. ( ^ . ^ 

f4 0 Integrated Test Facility. (ITF) allows the auditor to continuously 
; monitor the performaRce of the application system, by incorporating, 

dummy master records into the data ba|^ Once these record^ are , 
in- place, the auditor can prx) cess t^^ transaction's against them 
by including the test transactions'v/ith the live data during the 
normal processing cycle. The auditor -can then compare the 
processing results with predeter«mined results, 

- * * « 

^\ 0 . System Control Audit Review Files (SCARF) iny^^^ thel>^cement 
^"1^ . of auditor-designed tests within the ^application"" system program 
1^ co.de. During normal processing, the 'audit tests are performed . 
. on the processed data. Either processing exception or precleter- 
mined sample solution criteria is used to extract the desired 
records and write th^m on a review file. The auditor can then 
examine the review file and draw appropriate conclusions, 

0 Tj^cing gives the auditor the ability to follow (trace) specif- 
ically marked or tagged input transactions as they are being , 
^ processed, by the application system. It requires the insertion 
pf-addi^tipnal coda. int04 the application system ^and. an extra, 
field in the -transactions for the tag", this code generates a • 
processing record^ or tr^cHrn, for the marked transactions which. 
- can b? analyzed by the. auditor to determine if the processing 
is correct, „ ' , ' ' . 



0 Observation of personnel -^by visual, electronic or photographic 
}y means can assist the auditor in determining compliance with and 

atlfequacy of ^existing policies and procedures and in detefmining ^ 
erroneous or fraudulent behavior, . ' , / / 

0 Analysis by interrogation of existing data consists of- examining ^ 
j\ accounts, balancers or other indicative and history data to de-, 
* .termine if incompatible relational conditionse^ist (e,g,, mis- ^ 
matches between the data and source documents or other records). 

0 test decks .or test data can be^^used for the testing of new. or 
modified applications programs before they are placed .in produc- 
es, tion or for testing the application system's processing integrij:y/* 
In either case, a set of test p'nput transaptions is processed by 
the application system and the results are compared with pre-/ 
determined results. ? ' 
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a Interviews with management, users and systems personnel on either 
a formal or informal basis .can be used fo supplement system docu- 
mentation, provide a better understanding of existing policies 
and procedures, and. to verify compliance wi«i these policies and 
procedures. ' . r » , 

0 Program, source code review, for the purpose of a data integrity 
ajJdi/t,Jhould be used only as a last resort".. When information 
aooijt file formats, processing ^teps and control descriptions is" 
. needed, it is. better to use other documented .sources such as 

record layouts, system flow chafts, program >ogic flow charts, • 
. and program descriptions, y\nalysis of program listings is very 
-V time consuming and generally requires skill in programming and 
J detailed knowledge 0/ the specific programming language. In " 
/ cases where other dociper^tationns inadequate or nonexistent, 
program listings usually provid^ the most up-to-date information. 
Consequently, limited rev^iew of source codermay be necessary. 

0 Questionnnaires are a tra'dititnal audit, tool for- obtaining infor- - 
mation about an applicatibn system and for evaluatinfl controls • 

. to determine adequacy and compli.lince. . They are most effective 
when tailored for particular types of applications such as pay- 
roll, purchasing, inventory,- etc. and provide preliminary 
information for a more thoj^ough '.evaluation. 

I ' "i • ■ 

Code analy sis and mapping ^ is accomplished by~a software measure- 
ment tool that analyzes a^ program during it^ execution to deter- 
mine how many times each qrogrant\ statement was executed. While' 
Its original purpose»was tio aid program development, mapping 
can be -used by auditors to evaluate prbgram operation'. Howevef«', 
its use requires that the auditor have a basic level of Under- 
standing of both the appMcatioh system's- structure and application 
progranming. . ' , . ' , w 

Automatic flowcharting software consists of sb^are routines 
which convert program source statements into flow, charts which' 
graphically describe the program logic. The use of ^flowcharting 
sptwtare makes jt easier to understand the logic of a- program - 
and also guarantees ihat the auditor has a current flow chart ■ 
when ne is reviewing,^he^ applicatibn system. Howeve'r, reading 
the<flow charts usually .requires some prpgr.amming expertise. 
Flow charts are most. useful when the auditor is "looking at 
particular problem areas. As with source eode review, reading • 
.logic flowcharts may be .of .limited value in efuditing for data 
integrity., ' - : • 

, ■ ' ' \ , . . . ' 

• Procedural wajk-throughs cdlsist of the auditor following the ■ 
flow'of specific transactions through alV states of the system— ^ 
from their source until their processing is completed. An" 
auditor can perform ^ walk-through to verify his. understanding 
of how the system works,- to check thdt the system functions as " 

■ • 181' ' .' 




the existing documentation describes ancl, in cases where there 
is inadequate or no documgotation, to determine- actual system 
operation. *This. method, when AJsed in conjunction with code \ ') 
analysis and mapping and automatic flowcharting software', can ' 
provide the auditor with art overall understanding -of both the. 
manual and automated^ functions \x\ the^system. 

Undercover observations -give the auditor a chance to view norma1» 
system operaticyis- without the system pers^nel being aware that 
ti»ey are Being observed. -This allows th^ auditor to determine 
'.if stated policies ^nd procedures^are being complied with on a 
day-to-day basis and^to detect actions that might not be per- 
formed if the system's personnel kri^w they^^were being observed. 
Suc[|j^ctions might *incl ude employee fraud or embe7z.Jement . 

Surpri.se visilts , like ujyiercover observations, allow the auditor 
to view .-the s.^^em Oh^fer normal operating conditions.. Advanced 
'nriotice _of an auott^-feends to increase anxiety and induce abnormally 
good behavior in personnel.' ^ ^ ' . ' , 

\ 

Analysis of system activity logs , such as transaction, access, 
librar'y, operator and-console^ logs, will aid the auditor in • , . 
Evaluating compliance with existing policHes and procedures. , 
Following the analysis of ^le logs, the ajjditor may depide tKat 
the logs are^hot adequate for 1;heir ij^tended purpose or,.b,as^d 
upon the ^analysis/ that existing. policies,. and. pijocedures are not 
adequate or not being complied with*. . ' - , « 

Continuous monitoring and surveillance software / Software moni- 
'tors are programs which execute concurrentl,y with the application, 
-system .in an attempxt to determine resource usage and systerti 
bottlenecks. Surveillance software iDroyides regl-time monitoVing 
.of the application systeth in an attempt' to detect erroneous or ' ' 
exceptional events during processing". Specific, examples^f s.ur- 
veil lance software are the Int-egrated Test Facilfty and thef 
System Control Audit Review Files discussed previo<Jsly. 
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\ , ' .-^ EDlTgRS' NOTE 

A brief biography of the Session Chairperson follows: f 
■ ' , . , 

Dr. Jerry F^tzGerald was formerly a Senior Management System^s^Con- 
sultant at tho^tanford Research Institute and is currently Pr^sfctent 
of Jjerry FitzSirald & Associate'. He has also been a* state university 
Associate Professor in business data .processing and EDP auditing, ^ 
systems enginerer in a major medical* center, ^ senior '^stems analyst 
with a computer manufacturer, and an industrial engineer With a'phar^ 
maceuticaV firm. His specialized professianal comjletence 1 ies in: ^ 
planning/development of both computer-based and manually oriented . ^ 
systems for f ifiancial/industrial organizations, hospitals/medical 
centeir*s, ^and educjatiorjal /institutions. His expertise includes EDP ^ 
a^'ditingyEDP security, and^data communications. His degrees ar|; ' 
Industrial Engineering (Michigan State Lj. , BS) Business Administf 
(U. of Santa Clara, MBA),, and, from Claremont Graduate School, an"^ 
Economics^and a Ph.D. in Business. His most recent publications incliide 
Fundamentals of Data Commugj cations , Wiley/Ha)n.il ton tin press), "In- 
House Staff Versus Outside ConsuUants" , Proc. of the Academy of Man- 
agement, 35th Ann". Mtg., New Orleans, La., 1975; "Auditing EDP Sysjtems; 
Eight Are§s of Control", Data: Its Use, Organization, and Management, 
"Proc. of Pacific *75 ACM Conf^; and a textbook. Fundamentals of Systems. 
Analysis , _ John :Wi ley and SonSr 1973, He is^a membe'r of the Acddiemy of 
Management. . - . . . • ^ . - ' -'J-.^^ 





fge given to this 'session was: ^. ^ i} 

MMUNICATIONS : ' Wfiat are. the audit Approaches and tech- • . 
ues for, evaluation of comitiunicat'ions in an ,ADP" environ- ^ 
ment? Include considerations of hardware, 'software, qgd . 
' protocoTs.' " / 

Data cbn^nunications can be simply ^defiiried as the interchange of data ^ 
messages from one point to another over communications channels. Dedi- I 
cat^d or dial-up facilities can.be etnployed in a variety of netwrk * / 
configurations. ' , \g ■ . ; - ' * 

Thi5, session is to analyze the>^rious corfimuni cation environments and 
identify the' major aspects .th^ tlie auditor must ^^coasider to conduct *' 
an effectrve. evaluation.. Audit approaylies and techniques for^such an 
evaluation Inould be' developed/ , \ / , \ \ 



.The consensus report that follows was' developed and reviewed by '^l^he " 
entire membership of this session. * • ^ '* » ^ \ ^ ' 



'■^ 



^UDIT AND COI$*ROL OF^ 
\ . " \, * D^TA COMMUNICATIONS NETWORKS, * . 

A Consensus Report , , ^ ' 

^ . . ' 

/ / Jerfy FitzGerald, Chairm^ 
( and (alphabetically listed) 

, Dennis K. Branstad, Lynn^ Devnew, Milton t^erijan', 

- Robert Morris, Fred A. Stahl, ,Ken Susfffin . » " 

? .; ^ V ^ • ^ • ^ 

' ^ . ' ' ' : ^ ' .i' 

V ' • • - ' ' 1- INTRODUCTION'' • * 

This paper pi^|ents gui^elk-nes, rathet than a §et .of standards, 
tha't can he utiliz^ when C(f acting a data" communication se'g&rity ' ?^ 
audit. Ifc is the iiitent of^tjfe' committee that this paper form a basis 
from which' EDP auditors, either in government or privat| industrj', can ' 
develop methodologies to audit their organizations' data comffianication- 
network. Further Research in this area might enlarge upon these guide- ' 
Ixnes to develop a set of standards thit could be utilized, for auditing^' 
government or private- industry data communication netwofks. . ' ' 

Definitio n of the Special DatafCComiflunic'ation Audit " ^ 'J^ ■ 

- There- are many types pf audits tha^ (fan be performed. .This \)aper 
addresses a special ..^e pf aiidit that involves only those" computerized " 
systems that utilize a .data^ommunication ne^twork and further i« limited" 
to the review of the data- cbmmunications portion of these systems". A - 
speciaL data communications audit involves the end-to-en^. network, and{'. 
all pf its associated hardware, software, ;Qnd people.' An audit of thi^ "• 
nature should- be. Sonductfed p^rio'dically to determine whether" the "inf or"*- 
«mation being transmitted ' over the network ii beiiig properly safeguarded 
. from its. point of ori^nation to its final destinafion.; TheCf requency j 
of t'he -audit should- biased: on. the sensitivity of the data^and appli- ' 
cations atiliz4.ng the network. Additloiially, a data communications 
audit should be conducted whenever there- is a reksonable'diubt as to ' • 
the overall integrity of the network-. • ' . • . 



The^ Exposures ^ . / * 

, 'Data c9nLunications networks can be subjectSed 'to several categorieT 
of>xposare including those J:p/which any 'other bqsiness information 
.system piight be^subjected^ Yor the purposes of this audit th^ par-' ' 
^ticipants in thie^ workshop identified the exposures to be (these are. 
defined, in Section's/ of * this paper): ' ^ * " * . . 
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and omissions - - f 



Errors, and omissions 

• Disaster and disruptions 
^ Loss of integrity 

• Disclosure' 
» ''^ • * Defalcation ♦ 1 
( • Theft of resources. ^ 

w ' ' ^ ^ ' r 

How' to Audit a Data ^Communications Ne twork 



" is 
.shiula be 



^ ^It is assumed that the EDP auditor cpnducting a datl^j communications 
.audit has a general understanding cif how data communig^tjjpn systems op- 
erate^ ij.e.; how messagiss are' transmitted -over communication links. 

- ' . ' • > - ' \ _ ' 

LS the opinion of the cc2rfcnittQe fh^t a data coiranxin,! 'cation audit 
conducted as a transacdlon fclow analysis. Transaction flow 
analysis is a technique of tracing a tr^ngattion or group of transac- 
tions from the\point ;of original, feritry (the terminal), through *the *data • 
communication network^ to 'the computer. Using this technicme^, the au- 
ditor is able to evaluate the fl.qw of tralisactions, ^^the hartiware/spf t- 
wate, the transmission media, and| in some»cases, the manUaJ^ interface 
xor^trols tjhat involve the people -;|?ho^ run the network | The committee be-, 
li^yes thar it^is wise for the ax^^itor to .trace the '^low of trartsactions 
s4f|rting at both^endfr of the ne^tx/ork (t^mirial alid\c(Snputer)* and to rec- 
oncile the findings. The audit sf^ould be conducted^'for the gen'^ral data 
communications system, as well-as for each sensitiv6 application using 
the data communications network. ' * ^--^ 

To assist '\^p|the au<Jit, this^j^aper depiats a^ mat rix*^h\at matches 
the various resources ( terminals/ distributed iij^firfl ig^^K;^ c^munic^- 
tion lines/ an^'the like^ with the' preA^iously^nt-ioned ^xp&sures (er- 
rors and omissions, disaster/disruptioft€,Moss of iritegrit)^^ and the 
like) so. the auditor can deterjnine whichNresource may be soibject to wl\at 
type, of exposure. The resources are^vtisxed belov).and ?ire' defined in 
Sectioij 3 of this' paper (Figure 1 depicts the resources from terminals tp 
comguter)-*^"'* ^' ' ' * * ' . 



Terminals . *• ' ' * - ^# 



'Distributed intelligence 
Modems 

Local "loop ^ 
L 



ines : dial -ftp, point-to-point, ' multipoint, and loop . 
Multiplexor, concentrator, switch * 



Front end* 
Computer ^ 



^ 
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CHANNEL 
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CONCENTRATOR 
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Local L'oop i 
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• Software * 

* *^ » ' ' 

^ People . • * ^ 

The safeguard matrix (Table 1) lists resources^ down ttie l6ft-hand 
vertical axis, and^the exposure^ across the top horizontal axis. Within 
each of the/cells of ' the matrix, various safeguards are listed that the 
auditor should CQnsider when reviewing the security of the network. The 
safeguards 'are listed below^^^Ra are defined in Section, 3 of 'this ^aptr: 

Physical security controls ' ^ ' * . 
< (2) Audit trails ' • * *^ 

(3) Back-up . '.^ ' . ^ *' 

(4) Recqvery procedures * ' , • , ♦ ♦ 
A (5) Error detecticm/-correction ; * ;^ , ^ . » 

(6) * Authentication ' . - « * ' 

(7) Encryption r « 

. Operational' procedures ^ ' ; . ' ' ' , 

. ,(9) Preventive maintenance " ^ - ' ™ . 

. (10) • Format checking, 

(11) Ins'urance * ^ , • ^ 

(12) Le^al contrao-l; . . ' 
(L3) ,,F^ukt if blation/diagnpstics " 

,(14) Training/education - . . 

(1«5) Documentation • ^ , • ✓ 

(.16) . Testing ,4 . • . 



A 



(17) Reporting and statistics. ' ' ' * 



rin cSnductirtg^an audit^ any rgsource that ^is subject to -an exposiftre 
should have. some typje. of safeguard- that the auditor must consider.. In ' - 
doing this, the auditor would "Walk through** the data, communioations 
network and evaluate 'tjie safeguards lis.ted.for each specific resource 
versus its esjposure with regard to the specific application system. * 
This is an important poiat; the auditor should use." the matrix to review^ 
the communication security in light of each of the specific applications ^» 
thab-are utilizing the da.ta communications 4?twbrk.' 

Limitatioas ' * - * % . , - 



This pape^ 'is intended to be a basis for further research 'that may 
lead to industry /gayernment standards, for conducting data communication ' ^ 
audits. The ma'trix of resources versus exposures should=^ be' utilized-'ea ^ . 
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.' Table r ; ' J ' 

MATRIX OF, SAFEGUARDS TO AUDIT A DATA^ COMMUNICATIONS NETWORK 



Resources » 



Terminals 



Dist?rU^uted InV 
telligence ^ 



-Modems 



Local loop\. 



Lines; dial-up, 
point-tbVpoint/v 
, multipoint^ 6c Iq-QP 



.MUX /CONG /sxTitch 



ront-ehd^ 



Computer 



^rrors 
6c omis- 
sions 



2 3 5 
9, 13 ' 



6,9,10 
13; 



3,5,91, 
13 



3,5,9, 
13 



A,'.5>9; 

13 



3,5,9 
13, f6. 



13,16,.-. 
17 




Disas\ 
* ters 6e 
disrup- 

t ion's 



1,3,4,' 
8', 11 /" 



1/3^4, 
8,11 .' 



i,3;8, 
u - 



1,3,8 



3,4,8,- 
17 - y 




.f . ; 



Exposures 



Loss of 
integ- 
rity 



1,2,5, 
6,8,13 



1,2,5, 
6,8,1-3, 
16 • 



1,13 



1,5,6, 
7', 13 • 



5,^,7, 
13 > 



1,2,3, 
4,5,-6, 
7,8,13, 
16 ■ 



1,2,3, 
4, 5; 65 
■8,10, 
13',J6- 



'l->:2,3,- 

^;'5', 6, 

^,107 
U,16' 



Dis- 
closure 



I, 2,6, 

II, 13., 
17 



i;ii,. 

13,16 



l,ll,-,v 

13 - 



*i,7,ii;' 

13 



1,7,11, 

13.. 



1,7,11, 
13. 



1,7^3, 
16 ■ 



I;7,i3r. 

16' 



Defal- 
ca t ion 



1,2,6, 

8/ . 



1,2, 8 



Theft 
of re- 
sources 



1,2,6; 
17 . 



1,^,6, 
8 



1,2-, 6, 
8 



7^- 

1/2,6, ■ 
8 



1,2,6 



1,2; 6 



■1,2,6, 
17 .. 
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• Table 1 (Concluded) 



* 

■» 

Resources 


Exposures ♦ • 


Errors 
6c omis- 
s ions 


Disas- 
;.ters & 
disrup- 
tions 


Lo^s of 
integ- . 
r ity 


Dis- 
closure 


Defal- 
cation 


— ^ — 5 

'Theft 
of re- 
's our ces 


&ftware 


3,4,5, 
8,13,. 
►l5,16, 
17 . 


V.3,4,* 
XI, 15 


1*^2,3; 
475; 6, , 
. 8, 10, 
13, H 


16 ^ * 


.6,-8!,- " 
72, 15, 
16,17. ■ 


i.2;6i, 
12; ij- 


% 

People 

» 


4,678, • 
10, 11^ 

;3,-i4>- 

15,17 


'.1.3,8, 
71,12, 


1.^55/, 

^^-14, 
.15,16',. 
17 


,1.2,6, 
'8,12, . 
•13,14, 
.17. 


S1.2x-6^~ 
12, 17- 

r 

It 


— r-/^ 
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review ea'ch. application system that ia current ly^ using the datfe- communi- 
cation network. % The user' is adv,j.sed that^ there are i^me basic limita- /^ 
..tioas.that must b,e recognized^. ^ These .limitations, a-re as follows: 

• The safeguards listed in the matrix are intended only as . ^ 
^ guidelines^ not as standards^ ar^d should not be con'slder^jd 

aiy||nplusive with regard to a specific application" system/ 

• TOe^^feguards Itfsted will assist iji making a dat^- comrtiun- 
^ icatTons -system secure*; it ttiust.be emphasized that Security 

is relative,^ not absolute. ^ - • 



Safeguards li'ste^^ay not apply in all application . situa- - 
tiqns, and, therefore^' a general knowledge of data commun,-: 
ications is assumed. 

The. saf ^guafd'^ :onAdered imply the 5tate-of-the-art^methods 
in use at the time (1977) thi^ paper was written. * 



\ 
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2. USE^ THE 'audit MATRIX 



To ^conduct a data commur;iications security audit using the ''audit ma- 
trix, the auditor should first become familiar with the committee's def- 
inition of resources, exposures/ and safeguards. 

The auditor should then, for .each resource utilized" by each sensi- 
tive^ application on the system, fallow a four-step procedure: 

• ** * ' * ' 

Locate the resource on the -left-hand vertical axis^ 

^ Read across the row identifying each potential exposure^ ' 

' • Consider .eacKs^fcential s^rffeguard for applicability, given 
the specific Sppiicatior^ being run on the'rietwork. 

'•• 'For. each applicable safeguard, '-evaluate whether the currerft 
♦ implementation the' safeguard is adequate. * 

The matrix can^ additioa^lly, be used to audit a« general dat^ com-, 
munications system*. The prdcedure, although basically unchanged, would 
be followed to evaluate 6ystem ^ij'esources and exposures as they apply to 
the total* system^ 
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Resources 



3. - DEFINITION OF RESOURCES, 
^EXPOSURES; AND SAfEGUARDS 



pnri e?"^ following 10 resourbes^ are those^'-resqurces, thai -constitute 
ena-to-end data communications network (review Fieu^e 1). This secf 
defines each of the resources .j:hat are li'sted on fse mat;i^-^Kble 

• » ' • .i ■ : . 

. Terminals ^-The devices used .for inputs and/or outu^ut of obm- 
puter reeogniEable information. . \> - "-v 

• Distributed Intern i^enrP-.- The -provi^io^ of capabilities -for 
error detection eth€/or correction, authentication, message ' 

.formatting, data validation and check sums, protocol, and^ 
, . other logical and aritjimetic function f(5r validating ' 

the integri^ty of the data transmitted from the .terminal . 

• Modems — Modem is an acronym "for MOduJ.ator/DEModulatot 
The function performed is conversion of the data signals 

-p^' ^ terminal to -electrical format-acceptable for trana- 

/J^.- mis.sion on the. particular communication llpk's .employed and 
■vice ver^a. r ' , » 

Local Loop--The commuai cations facility between the 'cus^-- 
„ > tomer 's j>remisis and ,the communications -ca..r-riei? central 
offi<:e. ' The local loop is assumed ^f^'be m'etaHic pairs of 



wire 



Lines--The common earri^ facilities used a^ links in.Jrhe 
communications network between- central offlies. "These in- 
clude terrestrial and satellite facilities ' ' ^ ' 

- Di-al-Up: ' The switched telecommunication network and the 
various S||vices^.rovided therein, .V. , -Toll, WATS, CCSA 
(.Common C^trol Switching Arrangements). 



- Point-to-«nt PrJ.vate Lines: ' DfedVcat'ed leased facili- ' 
• ties betw*n two end 'points. /, 

- Multipoint or Loop qofefigured ■•Py4va.^^Qe : Viio4ted^^' 
leased facilities .shared among "Tsex^raF (:|ceater tha^ 

two) end points.. ' ^ 



Multiplexor. Concentrat 

- Multiplexor: A device that combines, in one data ^Sam, 
several da^a signals from Independent end points." 

- Concentra;:or: ^n intelligent multiplexor. 

- Switch: A dev£ce that allows interconnection between 4ny 
two lines connected to the switch'. ' 



• rronc-End Pr.ocessor -7A devite that interconnects the commun- 
. ications lines to thfe computer and periEorms a subset of the 
following functlons'r * ' \ 

' ' * , • : ' . • ^ ' . , ' • f 

- Code and speed conversion » - . * * , 

^■^ - Protocol ' ^ '\ - . ' ' 
^- Error detection and correction^ > ^ , \ 

- Format checking * « « ' * 
. - Authentication 

^ - Data validation* . " 
•'-'Statistical data gathering. 



Computer — An elecjtronic data processing device ^ferred to 
here ortly for i.ts communications processing capability. 

Software--The ins Auctions' in .the com^juter that cause. the 
communications'a^plication processing functions, to beeper- 
* formed; ' , 

^« - Peo£le- -The. individuals responsible for inputting data, 

operating and maintaining tha. equipment, writing the s^oft- 
ware, and nfanaging the data communications environment.- 



Exposures ^ ' , , , ' - 

The following six items depict> the basic areas of exposure that 
I'isted across the top'of^the ma.trix. This section defines the basic 
posures-'to which a data communication network is subjected: 

• Errors and Omissions --Inadvertent or naturally occurring 
- problems excluding those resulting from^. deliberate or ma- 
licious actions/ They include l)ut are not limited to: 

- Inaccurate data ' - , ' 

Incomple,^^ data - ^ / ' • 

Malfunctioning devices, lines, or software'. 

. , Disastets and Dis-ruptions (natural and manmade) --The'^de- 
l struction or temporary breakdown of the pe^rsonnel or tfa-' 
cilitie^s required for the communication osystem to func- 
^tion. This- results* from natural and manmade disasters 
such as : ^ 

^ ♦ ^- • ' 

- Common carrier breakd^own. ' • 

- Public utility tfrea'kdtJwn. 

•- Hardware/software breakdown, ' 

. . - The. occurrence of a series of events each with, low' 
probability causing cata&trophic loss. 
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Loss of Integrit\r --The conditioa that exists when tVte sys- 
tem', including its hardware, software) data, and conrigu- 
raUion is '^lot in one -of Its intended states,* i.e., it has 
been subjedted to accider>tal, ^ fraudulent or tirairr^iOTs* ac- 
tion or destrudtion. Mere disclosure is not included in 
/ / thi& ,def ihitiqn . (EhrroVs and. t)miss ions -were treated sep- 
arately in this mafcrix.) 

• Disclosure — The unauthorized exposure of 'information.*^ ^ 

• Defalcation — The intentional^b'reach of tha integrity of a 
system or its data by •an individual, or a ^roup of indi- 
viduals in a pasition of trust or performing their assigned 
.tasks. 

• Theft of Re sources --The use of the facilities- or services 
of ^ system for other than the intended purposes. 

./ . • 

Safeguards ^ ' 

•the following 17 safeguards are the major categories of safeguards ' 
that an auditor should consider when reviewing the* seci^rity of a data 
.communication network. This s^ctipn deftaes each safeguard. I-t should 
be npted th^t security measures applied to'data communication networks 
can be costly. It 'is of great importance that a realistic and pragmatic 
evaluation be, made of the pqtential threat as well as the possible safe- 
guards for countering the ^threat. to ensure a cost effective application 
of* thes.e^ safeguards . The. auditor should conduct a threat assessment 
with regard ti^a potential loss of the application involved, the proba-^ 
bility of that loss, and the cost of providing an adequate safeguard: 

' ' ' ] 

(1) Physical Security Controls --fhe use of locks, guards, 

. badges, censors, alarms -and administrative measures to 

protect the physical facilities, computer, data ^(ym- , v 
munications, and relat<|d equipment. * These sa^egudrds 
are, required f or-^.^^^d^e^t^i^itordng and controT for and * 
the physicafl pi;o)?fe'ctioif(lfcf .the computer and to, protect 
data communicafc4??Sfp^(gt}u^^Wji^^ from' damage by accident, 
fire, and environmental. ^azard,-^ both intentional and , ' 

^ unintentional in natori:^^^. These safeguards are employed 
to detect, deter/ preve^rt-, and^ report security expo- 
sures. 'Audit consists of determination of existence 
V of 'specific physical security tneasures, effectiveness 

of their functioning, and' testing of .reliability . 

(2) Audit Trails --A chronological record of system activi- 
ties that is sufficient to en^able the reconstruction, 
review, and examination oj the sequence of environments 
and activities surrounding or leading to each event. 
Selected journals or reports include; - 

- Computer Ibg-on/log-of f 

- Physical access log-in/log-out 

10-12 - • • ' . 

\' ' i94 ■ ■ * 



- Resource allocation and use 
-•Reconciliation ii>60ts^ to output^ , 

Frequency of* speciiic eventis , * - 

- Forward^and backward trancing' ^ • ^ . 

- NetwqrK *tftiiiza tlon* * * 

This safeguard;'is Employed to detect; recover^ correct^ 
or report security exposures. Audit consists of. (deter- 
mination of reasonablehesS; completeness^ and ^^ope.*> 

Back-up t-Tiie availabi-LLty *and protection of resources 
to be us^d to replace 'or d,uplicat,e those usecl in normal 
operation. This includes opera tional and written .pro- 
cedures for regular revie^ update^ and testing of 
back/up resources.. This safegXiaxKi -is* emploj^ed to pre- 
venjc loss^ and to correct or to help recover from^'er-/ 
TOYS. Audit should determine appropriateness 6f b^ck-" 
up techniques f6r risk involved. ^ 

^eco>very„ Procedui:es --Th'e actions^ . procedures^ or sys- 
"t^ems used to restore resourqes to 'normal dperational 
capat^ility in a^timely/ cost*-ef f ective manner. Audit 
shduld determine workability or feasibility of re- 
covery procedui^es. ' * * ^ ' - 

♦ 

Error De tection/CQrrection --Jhe technl^quesy procedures/^ 
or systems used to. detect and' correct errdoirs by meth- 
ods such as echoing; forward error 'correct^ion^ an^ au- 
,t*matic detection .arid retransmi^ion methodologies. 
Thi^ may involve validation throOg^h ' selective algp- 
rithmS; parity checks^ checld sum^ ettr^' This safeguard 
is used to detect 'and correct errors. The auditor 
should determine limitations of techniques^ procedures^ 
,or systems. * - • ' » ' , ^ 

Authentication - -The act identifying* or vet,i^*jSfIlg the 
identity;, authenticity; and ej.igibility of ,a termihal; 
^message; user; or computer. Authentication devices are 
used to detect^ prevent; and deter exposuVes. These 
include "but are not limited to: 

- User passwords 

- Keys- - *• . 

- Badge's , / 

- Message sequencing / * . ^ 

- Terminal /computer call back. * • . • ' * 

- Network protocol ' •'■ \ 

- Encryption. » . 



10-13'' 

195 



The auditor sh^5uld determine existence and comt^letjfene^s 



of the 'safeguards 

Enct-yption -^trans formation of data to hide its o/iginal 
cop^e.nts or prevent its undetected modif ic^^on / The 
^considerations ai;e : « . ' ; / ' 

-.Specified precisely to mee.t some standarti^ e/g.^ the 
NBS Data Encryp'tion Standard. ' ^ 

'r Matched to vulnerabilities ancT^haracteristics of the 
communication 'systdn and the data involve<^./ 

• / ^ 

- Various ways 'to encrypt^ e.g.) ltnk-by-lin)c or end-to-" 
end. 

- Requires administrative procedyires to select keys to . 
be used^ dictate' wh,en to change thei^^ and contrql their 
distribution. * 

/ . ' / 

- Integrate into, system design in future applications 

when justified by the appropriate cost/risk analysis. 

- Add communications overhead to distribute keys^ ini- 
tialize and synchronize devices, and yt'ecover from 
communications errors.. 

Auditor should^irst evaluape vulnerabilities of system 
and data., review the objective's -of the encryption sys-., ' 
tem, and then measure the effectiveness^ of the jihysical'^ 
and administrative procedures supporting encryption J * 

Operational Procedures -rThe administrative regulations/ 
policies, and day-to-day activities supporting the se-'^ 
>c.urity safeguards of a data communication sy^stem such 
as; • , ' • 

. /' . . ' 

- Specification of the objectives di ADP secjiirity 'for 

an organization, 'es^Secially as 'they relatre to data 
communications. ' - ' / 

- Planning for contingencies of security "events;*/ in- 
cluding recording of alL exception cbnJitibns and , ^ 
.activities . - • \ % 

« 

- Assure management that other saf^uards are imple- 
mented, maintained and audited, including •ba*ckgrQund 
checks, security clea^-ances and hiring of people with 

''adequate security-oriented character^isticf ; separa- 
tion of duties; mandatory vacation^. ' -r^ , 

- Develop effective safeguard for deterring,, detecting) * 
preve)|lting, and correcting undesirable^ security ' 

■ events . * . ^ , 

- Cost effective,, dftp resulting ' in ■ related benefits 

^ such as better efficiency', /improved relj^abilityj and 
economy, " j J * . • ^ ' . 
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Auditor should look for the existence of current admini- 
strative regulations, > security plans, contingenc^y. plans, 
risk analysis, personnel undetstanding of management ob- 
jectives, and^ then review th^ adequacy and* timeliness of 
the specified procedures in satisfying these.' 

Preventive Maintenance --Scheduled diagnostic testing: • 
cleaning, replacement, and inspection of equipment to 
^aluate "its accuracy, reliability, and integrity. This 
includes: * • ' 

- Develop schedules for testing and repair. . . 

- Ensure that maintenance, personnel are given- the time 
and resources tQ deter or preveat failures of 'equip- 
ment. ' * ' ^ 

- Keep inventoty of replacement parts^ based on failure 
statistics, such as Mean Time ■ Be'tween Failure (MTBf) 
for each device. ' ^ | , . ' ' 

- Yseep maintenance recoifds and aaalyze them for recur- 
ring problems or statistically unejjpected security 
exposures . 

- Perform unscheduled replacement or 
cific devices 'to detect unauthorized mbdification 
("bugging," etc.). This reduces'the likelihood of 
failures during critical periods and, a6 aj by-* 
product, detects unauthorized modification; of re- 

■ sources . - ^ . . 

Auditor should review maintenance scne^ules,! records, 
inventory, of parts, "downtime/' cost-to-r^paiir-or- 
replace ■ charts, and compare these with those of sim- 
ilar, systems . 

Format che'ck^ing '-A ijiethod of verifying data jas being 
reasonable through checks and balances. Deyelop au- 
tomated verif icati^on system to detec 
using methbd^s such as range checking 



testing for spe- 



record counts, alphabetic characters 



t data dntry errors 
(nuijierieal fields)^ 
J-ti numeric fields. 



field separators, etc. 

Auditors should evaluate areas wh'^re format i checking can 
be used andoverify that ^adequate che cks, are made . 

jC1i| Insurance --Fioancial protection ag'aj.nst pnajor losses. 
Insurance is used to share a' potent], al or actual loss 
and to protect against or recover from m^jor disasters 

by bydgetin^ resoiSRrceSv over thi^* long^ terip. 

<■ - <, j * j 

Auditors should evaluate whetfier protection may be mor^ 
easily obtained from alternative safeguards, and that 
major catastrophies will not expose the 
unacceptable risks. 
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(12) Le:Ral Contra.ct -.-An ^agreement for performing, a specific 
' ^ .service on a specific coistang basis^/^general I'y incurring 
specific liability. Examples inci^ide bonding, conflict 
of interest .Agreements, clearap^s, nondisclosure agree- 
■ments, and the lil^e. Other ^-^^mpJLes ^ include ; 

liability for** specif ic security 



Agreements establishij 
events . 



Agreements notyix> perform certain acts oV a penalty 
will be incxr^eS. ■ . y 

Auditor ahould^jre/i^w the legal document fdr adequ'a'cy 
. - and jppexect^jrfh afforded.. 

(13) F^Hlt Isolatibrf/Diagnos tics --The techniques used to as- 
xdertain t:l\6 integrity of the various hardware/software 
/' cotnpoKents comprising the total data communications* enr ' 
tity:, These techni^oes are used to audit the total^en- 
viropmept' and to isoi%te the^ offending elements either 
on a perio<Jic basis or upon deflection of a failure. ^ 
Th^e techniques include: • • ^ . 

• - Diagnostic software ^utines 
'/ / . 
T /Electrical loopbaok > ' ' ^ 

-|Test message •generation * 

'W A-^dininistrative' and personnel procedures. 

y ''Auditor should review the adequacy of^ the techniques 
ised tor- fault 'isolation . . ■ . 

il4) iTr^fning/^kicat ion - -Training --and education of em'ployees.- 
serves boW to aid in preventing problems and in coi>- 
recting them when they' have oc'curre4. It serves to ^ 
clear,ly define responsibility and to familiarize em- 
: ployees with ^ccepted -procedures * 

Auditor should review ongoing educational policies. 

» ^ Education al^o includesjtraining in the wh^sr-incliiding' 
.why security and" cotyfrols . are^ important to the prgani^ 
'zation. The potent/iaj. repercus'Slrons -df a failure a^id 
the. need to follow procedures or observe controls should 
^Isb be addressed* * 

* ' i: * ■ \ 

Auditor should ensure that management isr aware of the 
* '° 'tfe^d ^nd" advantages of education apd that training is 
used on a continuing basis.. 

(15) Documentation - -Documentation is a' precise description 
' of prpgrams, hardw^are;^ system 6onf iguratij^, and pro- 
^ cedures intended tp assist in prevention or problems, 
^ , ^ .identifying" the causes of problems, and recoverit^g^lf rom. 
. the .problems." It^should be sufficiently detailed to 
^ assist in ^reco'nst,ruc-ting 'the system from its parts. 
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Auditor, should determine Chat documentation exists to 
the extent required t|o meet reasonaBle anticipated n4eds. 

(16) Testing --The techniques used to validate the*hardware and 
• software operation to ensure integrity. Testing^ includ- 

' ■• ing that of pers^nei^ shou»W uncfover departures from 
specified operation. ^ • 

: Auditor shoul^ determine that te,stirfg exists 1:o the extent 
required . • ' , . 

(17) Reporting and Stati.stics --The gathering and reporting of* 

infor'mation- which defines the usage of all facets of the 

data 'communications entity. The generation of exception 

reports for management including: 
* 

- Traffic statistics . » 
Maintenance statistics 

- Error performance 

-'Teruiinal usage by time and activity. 

^ Auditor should 'determine that reporting and stat*istics 
' lexist to the extent requii^ed to me^ future planning n^eds 
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Defense Audit Service' ' * ' 
Philip n, McLellan 
* Royal Canadian Mounted Police 
Albrecht J, Neumann, Recorder ' 
National Bureau ofStandards 

J 



Michael J: Sopko ' 

GTE Service Corporation - - 
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Price Waterhouse Company • 
Robert Stone 
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From left to right: ^ Richard D. Webb, Philip M. McLellan, Zella G. 
Ruthberg (visiting Vice Chairman)., Robert Stone, Leo Deege^, Michael J, 
, Sopko, Albrecht J. Neumann 



Note: Titles and addresses of attendees can be -found in Appendix A. 

11-1 . ^ 

•" . ■ - . 200 ■ ■ ■ 



: ^ ■ ' ' ' . ' . • ■ . • . 

• ' - EDITORS' NOT^E ■ ; . 

A breif 'l^iography of the Session Chairperson follows: 

Mr. Richard D. Webb is a Manager in the Executive Office of louche^ 
RoSs & Gompany. He is responsible for research -and ^ievSlopment of ♦EDP 
audit pblicifes, EDP audit 'techniques, and EDP audit training. He had 
signifidant responsibilities on th^ EDP audjt team that investigated the 
Equity Funding situation for^ the Trustees in bankruptcy. He has design- 
ed and implemented audit software packages and' has been a financial and 
cost accfeuriting systems consultant. Mr. Webb is a 'Certified, Public Ac- 
countant (IL) an^^a member of Via American Institute of Cer.tified Public 
Accountants where* he is ChairmaVof the Audit Software Sp'ecifications 
Task Farce; a merpber of . the Cmputer Audit Subcommittee; and a member of 
the Computer Audit Techniques and Approaches Audi.t Guide •Proj^t Team. 
He was also a member ^of the tasR forces that drafted the AICPA audit 
•guides'entitled, "Audits of Service^Center Produced Records" andi"Au(li- 
tar's Study ^nd Evaluation of Internal- Controls in EDP Systems," He is 
(a member of the Board of Directors of the New York Chapter of the EDP 
Auditor^ s Association arid a' member of the. New York Society of CPAs^ Mr. 
Webb, received -his BS in accounting f rom •tlie University of Minnesota. 



The charge given to this session was: 

^ ' ' .. .. 

• • POST-PROCESSING AUDIT TDOLS AND TECHNIQUES: ' What are the post- 
^ . *prOgpssing audit tools and techn-iques a\(ailable' or ^ needed for the 
effective use of the various systen^ journals and logs in* an audit 
of qonputer -security? J' 

Many different log^ and journals are produced^ or can, be produced, that 
ppovide important information to the auditor evaluating 'computer 'secu- 
rity. Two of the- major problems that the auditor often encounters are 
the overwhelming volum^ of v^nformationSancI inadequate analytical tools. 

This session is>^to^consider the type of information, needed, the most 
effective and efficient method^of, capture, and the tools and techniques 
required fof analysis. Consideration should be given to what toQjs are 
currently'^available as well as "ttnJse needed tp be .developed. 

• . ■ • ■■ ^j^, ■ 



The following is a consensus' report initially c6yiewed by .th6 entire 
group. ' , ■ M ■ 
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POST PRESSING AUDIT TOOLS ANd' TECHNIQUES ■ ^ 



A, 



by 

* ^ ' » \ ' A. "j. Neumann 

^ ^ • ' ^ ' N. Statland 

" ^ ^ > R. dV Webb 



1. . INTPODUCTICW * 



, This paper suilnmarizes !the disotissions and conclusions of .the 
session dealing^ with post processing audit tools and techniques. Il^e 
'group consisted of a mix of _ external and internal auditors, security 
specialists and »copnputer oi;iertted genecalists. Early iij the 
deliberations'" it >;a^ agreed* upon 'to dbvelop, and- adhere to an outline, to 
.diScuss some* basic definitions, and to agree on a scope for a, security, 
audit. / : ^ ' 

Based on a common understanding of the scojpe of the problem, we , 
agrefed to '.look at available 'data by dividing the total system* into 
system access, igput , processing , and output areas,.* We would attempt to 
determine Jb^icaJ> security aiidit information requirements^ 'i.p.-what 
information^.would ^ auditor need in the post-processing envir"Onment to 
Ejerfprm a security audit, and what information* might be needed that is 
usually n6t availajjle in today's environment. ^Ndxt we would assess 
existing tools and techniques, and identify needed techniques. ^ ^ 

The authors wish to acknowledge, many contributions made during tUg^^ 
Miam;L meetings and' constructive comments made during the review' of V 
several draf^ versions of this paper by L. ^Deege, P. ^M. McDellap, Rt 
Stone, and M. J. Sopko. H, Robinson arranged the original session but 
was, hew^Ver, unable to attend because of a last ^jTinut:e emergency. He , 
did however contKibute to drq^fts of this paper. 



; 2. -CBJECTIVES OF A TYPICAL SECURITY AUDIT 

The post processing activities of the auditor are presented Yiejfe in 
.the context of a security audit and include conf idefitiality/ ijrtegrity, 
and availability Qf data. • Uney also include the ^egtee of ^ compliance 
with af)proved procedures. Our 'discussion was^intended to encompass 
environments ranging from those requiring very little security, to 
environments ^t the tJati'onal Security ^evel. AlsO, the. context of the 
discussion does not specifically addr-ess or exclude aOdits v^ere the* 
objective is an opinion on: thfe financial statements; system efficacy; 
system- efficiency; .or v^iether .the results of the syltem are used 
effectively. 1 • . * ' !^ 
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General objectives of such a security ^udit-wdre agreed to bfe the 
determination of th^ existence, scope and adequacy' of roritr(3)ls in light 
of the level of information pcotec^tion required by the pature of the , 
system\ " ' * . ' • ^ 

Several specific objectives were noted T ' ' ' * ' ' 

a. JDetermine that all transactions^ were completely processed and that , 
they were processed once and only once, (uniqueness of transactions). 

, ♦ * * ' ^ ^ 

b. Determine that each transaqtiorf is complete, accurajtfe and authorized. 
(comt>leteness, accuracy, and authorization controls for ^transactions, 
i.e. transaction integrity) . ' [ 

c. Determine that processing was co^nplet'e, accurate, ai^d authorized, 
(completeness, ^-accuracy, and author izatioo, controls of processing, iVe. 
processing infegrity) . • , - / * 

d. Determine that distribution of processing results was made only to 
authorized recipients, (distribution control). 

.A - ^ ■ ' . ' - . . 

e. Deterfaine that (Beta and the required use of system resources .were 
'recoveijabl§r.v ('recover ability control), ' ' - 

f. Determine the ability to detect*and analyze security 'violations, 
(detection and analysis capability, i.e. violation control). 

It was understood that the auditor woulq have to first "understand 
the system" being audited in ojrder to. work tt)wai?ds the stated 
Qbjectives. Discussion of security audit 1^3 to formulation of the 
foIloVing de£initior>s. 



J, DEFINITIONS . > ^ i 

. ' ^ Computer Security — ^The protection pf system data and resources 
froiji accidental and .deliberate ^threats to confidentiality, integrity, 
.and availability. / ^ - ' * x ^> 

■ - ^ ■ • V 

Computer Security Audit — An examination of computer security 
procedures and measures for ttl^ purpose of evaluatingtheir ^^adequacy and 
degr,ee-of compliance^ vith established policy. 

Note: 'Ihis^ definition coyers cori^ter security, x^thec than data 
security, which is included irf the broader concept. It was felt that 'the 
definition of security audit in FitS PUB 39 dealing with data security 
only sl^o^Id be broadened to the definition. given here. 

Post Processing Audit — The post-facto analysis of input, processing, 
and output intormatton for* the purpose of validating ccxnpiiance with 



.pre-deter mined system requirements including those for ^ecurity, 

* ' ' * 

Log. — ' A, chroFjorogjPcal record of data elements re'presentirig specified 
actions taken for specific purposes during system operation, '^Data 
element" is used iiere in its broadest" sense to include application data ' 
as well as system, performance related data etc. 

s D 

Tools VS. Techniques — A technique -is a method of accomJ>lishi-ng a^ 
desirfed' objective; thus a technique .may consist of procedures that* > 
contain' several tools; or a technique may empioy sever al»' tools * 
^alternately. For example ^udit software is a tool that ca^ bfe used in 
^many techniques, . ' - . * \ - 

transaction — A collection of dat^ about an event. It m.^ be process6^ 
or rej^tedr but from an auditoi:'s viewpoint should always be ^recorded, 
Itie term is u^d here in its broadest sense from an operator .action at a 
terminal served by a computer to a financial transaction or a textual x 
message, ^ ^ ' - ' . , . * 



4, SCOPE OF POST PRCfcESgING AUDIT " ^ ^ 

• ^ ' \ ' . ^ . . ^* ' ^ ' ^ ^ 

, While the scope of a post processing 'audit extendi beyond the EDP 
system proper and includes review of manual* and automated controls, this' 
discussion, deals only with techniques, and tobls cover-ing the" EDP system 
-pcopei;-. That* is* the audit covers processing of transactions from tUt^ 
J^ime of initial conversion of data through in.termediate processing ' . il 
stages and telecpirimunications ta the deliv.ery of output, The mode of ' . 
processing, (that is, on-line vs, i)artch) was nb^t considered to^ be a ^ 
limiting factor, though several ofvthe iogs discussed may be appropriate 
pnly in^on^ or the other mode. The auditor is assumed to have"^ 
sufficient knowledge of igystemh^ be able to j^udge the ijtipasj: of system., 
pei;fomance on security and also to effectively Review manual ar'eas ' 
prior DD, conversiort^ and subsequent to output, ^ Tiq\tce 1 'sh(^ in \ 
diagrammati? form the. scope of .post-processing s^QuritJ audit, \ o'' 



5. INFORMATION REQUIREMENTS^ 



Achievement 'of . the objectives" of 'a- security audit generally 
requires jlnformation the following areas: ACCESS; INPUTr 

PRDCESSI&'and OUTEOT, The pudifeor should review each of th^ ifeas and 
Took for information detail in a log showing the following fiv^e basic 
types of information labeKed : m&, FUI^TIO^T, WHAT, STATUS , and TIME,** 
(These are illustfated in tables T^through 4)/' 
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INPUT 



ACCESS 

T 



|— PROpESs]--^ OUTPUT I 



LOGS 
JOURNALS 
RECORDS 

ie: 



TOOLS 

"T" 



1- 



AUDITOR'S 
OUTPUT 

nz: 



-A 



AUDITOR'S 
CONCLUSIONS 



FIGURE 1. POST PROCESSINd^CURITY AUDIT 
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TABLE 1: S-YSTEM LOG ACCESS INFORMATFON 



WHO 


FUNCTION 


: WHAT 


STATUS 


TIME 


USER ID 


ENTRY 


r^SYSTtM ID 
& DEVICE ID 


SUCCESSFUL/ 
UNSUCCESSFUL 

< 


D-T 


USER ID 


EXIT/ ; 

RELEASE 


SYSTEM ID. 
& DEVICE ID. 




D-T 



b=T)ATE 
T=TIME 



v.- 



TABLE 2: INPUT LOG INFORMATION 



WHO 


FUNCTION 


^HAT 


STATUS 


TIME 


9 

• 

TASK ID 


REQUEST 
T.0 pPEN 
FORJ^EAD^ 


RESOURCES 
I.E. FILES, 
DEVICES, 

PROGRAMS 

' DATA 


SUCCESSFUL/ 
UNSUCCESSFUL 


D-T 

1* 


TASK ID 


*READ 


FILE, DATA 
ELEMENTS 




D-T-SN, 


USER ID 


ENTER 


TASK ID 


II 


D-T 



D=DATE 
T=TIME 



SN=SERIAL # 
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TAB.L^ 3: PROCESSING LOG INFORMATION 




V * 


WHir 


FUNCTION 


WHAT 


STATUS 


TIME 










TRANSACTION 








* 


TASK ID 


VALIDATE 

f 


TYPE 
CONTENT . 


. N/A 

» 


IM/A 








- FORMAT 




VALID/ 
. INVALID 


D-T-SI\h 


• 




TASK ID 


LOG 
RECORD 


TRANSACTION 


EACH ^ 
TRANSACTION 






TASK ID 


COUNT & 

. Qiri\/ll\/l ADI7C 

' oUIVilvlAnl^t 


II 


• N/A 


N/A 






TASK ID 


FORMAT 

LOG 
RECORD 


TA^ COUNTS 
& SUMS 


N/A 


D-T-SN 






TASK ID 


UPDATE 


MASTER 


N/A 


N/A 




4 


TASK ID 


'SAVE 


MASTER FILE 
LOG. 


NORMAL/ 
ABNORM/\L 


ri— T_<iM 
^OF - 
TRANSACTION 






TASK ID 


, SAVE 


PERIODIC 
BACKUP FILE 


N/A 


, D-T--SN 










DATA BASE 








1 


TASK ID 


COUNT & 
SUMMARIZE 


LOGICAL FILE 
FOR EACH 
TASK 


NM 


D-T-SN 


f 










" D=DATE SN=SERIAL # 








> 




. T=TIA/IE 






\ 


•■ ■• % 
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TABLE 4: OUTPUT llOG INFORMATION - 



WHO ' 


FUNCTION 


whaX^ 


STATUS ^ 


TIME 


TASK/ 
USER ID 


REQUEST 
. WRITE 
(UPD^E) 


FILE ID 
DEVICE ID 


SiJCtESSfUL/ 
UNSUCCESSFUL 
DEVICE/STATUS 
CHANGE 




TASK ID 


WRITE 
(UPDATE) 


DEVICE ID 
"^FILE ID \ 
MACHIME OR, 
HUMAN 
READABLE 


COMPLETER- 
INCOMPLETE 

* 


D-T 



D=DATE. 
J=TIME 



^ , ' ' WHO identj^ies t^e.cadse or initiating force of a transaction. The 
cause may ^be» ^"person or a process, manual tasks ^^or ^ program. 

The .FONCTION, is descriptive df a processing action such as "entry", 
g?. "request to read",'' 'Validate" , "count" et'c^ ^ ' ^ . 

Ifee it^ms^ label led yHAT identify objects of the processing action. 
They may-be files, devices^ programs, or data elements., 

^ ^ / ^ ' • ^ - ^' 

Hi^ STATUS infor^nation'refei:^ to the funcjtion and the associated* ' 
cause and objects. An action may be complete or incongiete, correct or' 
V ^.ijcorrect, etc. ' " - ^ . ' ^ 

TIME jJrovides a date-time stanp associated with the recorded action 
aiqd status. It provides Basic ^time information which can.be used to 
^ . determine audit trails, and in general to trace system continuities. In 
some Cases a transaction oi; record serial number will be associated with 
^ (Sate »time stairp. . ' 

I , 'Tables*! through 4 show typical, information cequirements in tabular 

forn). These tables are not all :^iiclusive'and should not be considered 

• complete in any way. They do illustrate a train of thought, and indicate 
a methodoJipgy which, could be used, to check security information 
requirements available in existing.' systems, and those to be specified 
^ for future systems.. No time sequence is to be inplied by thfe position of 
the rows in the various tables. Each line in. these tables forms a basic 
record "^of information pertaining^ to" .security, .which mayte recorded or 
logged and then processed at a later time for security audit purposes! 



6. TYPICALLY AVAILABLE INF0R4ATIt)N 

i In most existing systems a variety of information is available for 
post-processing audits. A variety of 16gs are prepared routinely for 
accounting purposes, system maintenance and fot system performance- 
monitoring. A, conscde log may routinely record ard print out coded 

* system malfunctions in terms of error ifessages and times of occurrence. 
An event log might also record terminal ID and user ID of successful . 
system entries. It, may ^Iso record* unsuccessful entries and associated 
passwords used on th^t occasion. Every user cqramand, the ;time of the- 
command, and terminal and user ID. may also be logged. ^From an EDP . 
department agcounting standpoint there should be records of the progranf 

. or job run, the various measures used in billing (connect time, C?U • 
time,* resource units etc.)> the user or organization ID, etc. Some of 
this information is useful for^ security audits. 



• n-io ^^^^ 
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.Security related information should include time of actioptr type of 
action^ recor^^of unauth9rized passwoi^ds used, resource control, ^ and 
otiier, means jused in the violation. \ 



'J. imjSTRATIVE EXAMPLE: ELECTKX^IC FUNDS TRANSFER. SYSTEM 1' ^ 

.. ■ ■ :■ ■' .. .. ■ 

- The next paragraphs illustifate security iriformation requirements in 
* the context of an electronic, funds transfer systeir^. Figure 2 ^hows a 

system block diagram, majors system components,. ajfi[d various logs used for 
-security purposes* A ^timber of retAil terminals arfe connected" to ei 
regional cOTimunication^ cohtrjoller./ Sever&l of these controllers may be 
connected to bank cdnputefs or, to each othet. Records and logs are 
maintained at the communication coiAtrollef-s and at central fcank . 
ciximters. , ■ ' ^ ' ' W 

^Bie controller maintains a rfefeerence log and a journai^i ^ft)ur i][iajor 
software functions ate postulated ^' for the central computer: the 'v- ^ ' 
operating system, and the input, processing and outpUt functioris,. All 
of these maintain appropriate jlogs and records for security purposes,. 



7.1^ Remote . Terminal 'Procedures' 



Procedure^ at the remote^ terminal are designed to build up security 
information in^ the various logs. A customer -is identified by -a personal 
identification. number 'to resttict access to appropriate file segements. 
A transaction type n^y be entered, which permits validation of the 
terminal' use for the particular type of transaction. A further cheqk 
may be made on the terminal identification, which may be hard wired. 
Additional authorization codes may be requir^ tq permit"* credit 
pperations, adjustments i.e. returns, artc^high value debit transactions. 
Each acknowledgment o^ a transaction is identified with a sequence 
nuni)er, 'which is generated in the termihal. ' ; 



7*2 ^e^s'age Security at .the Switching Computer. 



' Messages' ace formatted into message headers anc? the message ^ 
/content.^ ' ^ . • • ^ 

gi>2.1 Message Headers: A header usually wi^l contain Che following 
information: " ' ^ • - : 

-Originating terminal 'ID 
' ' Message- type designator - ** > 

Priority code ^ \, • - 

t^ssage sequence number (assigned at each 'terminal)'^ 
Rout ing^indica tor ' s ^ 

Message character count ' ' ^ 
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I RETA(L 



REQUrREO PROCEDURE 



REGIONAL 
FRONT-END 
CONTROLLER 



TRANSACTIONS 
SWITCHED 
TO OTHER 
REGIONS . 



r 



A N K COMPUTER 






It 


1 

I- 




OP€RATINp 
^ SYSTEM! 


/ e6it/ 
vjalidation 


PROCESSING 


OUTPUT ' 


/ 

C / 


/' • D . 


■ 1 

■•|h 




PasswqIrd 
tabJe 


..BUILD 

/ .? ACTION . 
^ CONtROL 

, t^6tals . 


□1 if'i r\ 
qUILU 

. MASTER » - 

FILEiCONTPOL 

^ TOTALS 








* ' ^' 




trap , 

PROGRAM 


' LOG 
f^06uLE 


)LOG ' 
MbDULE 




■ . 

■ / f 


'■{■■ ■ 


* * 








PERIODIC ' 
BACK*UP 
> \ FILE 



FIGUI^E 2. SECURITY CC/NSIDEI^ATIONS WITHIN EFTS SYSTEM ARCHITECTURE 
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' . . ( . ^ 
1.2.2 Message acT^wledgment and release. After validation of the ' * 
message character CQunt, the pitching conputer is^ccountable for each* 
messag'e until the' the/receiving unit e.g a^ terminal, host computer or , 
another switching ^center acknoy/led^es. receipt 'of the message. If 
"message count/ origin ox^ destination codes are invalid, retransmission 
is ^requested, -using th^-^same message sequence number. 

' ^.2 A Ledger \3alahcirig. By maintaining" a listspf input and output 
actions- for each message, ledgers are maintained in a<:ontinuous state ' 
' of balance, ' , • 

• 

7.-3 Conjmunications Processor Logs 

All jnessage tieader data are. maintained on the reference log, v^ile 
menage, contents are stored on 'the ' journal log. ' 

7.4 Bank Computer functions and Logs* ' ^ . 

The input function primarily deals, with validation and editing of 
the tt ansae t ions; A transaction log' is maintained. The. operating system 
ftiaintains a system access log, the 'processing function maintains a 
master file log, while the output module maijitains periodic back up' 
files, whicjh^ may be used .during system faiiijres to reconstitute fecords 
and files. T^lp 5 shows' data, required by system log. Sign-on ancj 
file entry wdiud require use- of encrypted p^g^rds, with associated 
, indicators showing vtiich files, devices, pro§^jn3» maty be us^. TablB 6 
'Shovfe data requirements fqr- editing and val^idating of iiiput ^ ' 
transactions, while tables 7 and 8 show data requiremen^is ,for proc6ssiiig 
and updating / and for output. ^ ^ ' ^ 

y ■ ■ ^ ~ . y .. 

, , 8. POST PROCESSING- TECHNIQUES - ' 

Several post-processing .techniques v^re^ identified by the vADrking - . - 
group. They aje presented here by area and witfiout guidelines for use ' 
in specific circumstances since useW a specific technique would ^ 
'require the auditor to consider seveiral factors such as timing and cost. 



8.1 ACCESS 



^8. r. 1 Unsuccessful accesses . List^l unsuccessful Recesses by level of' 
'security in order to determine who accessed, and v^y attebpt was 
unsuccessful. Determine frequency and quantity. Determine 
characteristic patterns "and compare to^ authorization table, 
aid in detection of unauthorized users. 
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TABLE 5: OPERATING SYSTEMS- 
SECURITY ACCESS CONTROL LOG D/CtA 



WHO 



FUNCTION 



i 



WHAT^ 



STATUS 



TIME 



SUBSCRIBER 

ID \ 



JGN^ON 



SYSTEM 
DEVICE ID 



SUCCESSFUL/ 
UNSUCCESSm 



D^T 



SUBSCJJIBER 
' ' ID 



RELEASE 



SYSTEM 
DEVICE IP 



SUCCES^fUL/ 
INSUCCESSFUL 



D-T 



SUBSCRIBER 
ID, 



ENTER 



TASK ID 
TRANSACTION 
TYfE 



SUCCESSFUL/ 
UNSUCCE$SFUL 



;D-T 



TASK ID 



REQUEST 
TO USE 
(ACCESS 
FOR READ) 



RESOURCES 
I.E. F.ILES. 
DEVACES. 

PROd^AMS, 

PROCEDURES 



SUCCESSFUL/ 
UNSUCCESSFUL 



it , 
D-T 



D=DATE 
T=TIME 



COMPLETION OF TA&KS 1&3 V^ILl RfOUIRE USE OF A STORED, 
ENCIPHERED PASSWORD WITH ASSOCIATED INDICATORS OF 
, WHICH FILES; DEVICES, PROGRAMS, EJC-JHIS TASK MAY USE 

•'A "TRAP" PRbGRAM SHOULD BE USED TO NOTE OCCURRENCE OF*UNUSUAL 
TRAFFIC PAHEftNS. . - 



TA&IE 6: SECURITY ^EQUIREMEM,TS DURJNG 
EDIT/VA.LIDATION INPUT TRANSACTION'S 



-Who 


FgNCTION : 


llVHAT . , 


STATDS 


. TIWfE" 


TASK la 


. VALIDATE^ 


TRANS ACTIQN^- 

O fl 1 L. IV 1 ^'-.^^ 


~ W/A . 


■ NM . 


TASK ID 


FORiyiAT/ 
WRITE LOG 
''RECORD 

r' 


1 , • ■ 
TRAN$ACTIjON 


WAUD/ 
INVALID 


. D-T- ' 
(TRANSACTjtaN 
SN.(INCLiJDING 

TERMINAL) 


TASK ID 

« 


COUNT ^1 ADD 
TO CONTROL 

'"rtJTALS 
MAINTAINED 

FOR ^CH 
TERMINAL BY 
TRANSACTION 
TYPE 


r 

TRANSACTION 
& SELECTED 

DATA,. 
ELEMENTS , 

r 


If 


\N/A 



D=DATE T=T*ME SN=SERlAL# 



^ TABLE 7: SECURITY REQUlREMENT$.t)URiNG 



PROCESSING/UPDATE OF DATAs 



WHO 


FUNCTION 


WttAfy^ 


STATUS. 


. TIME 


TASK ID 


UPDATE' 


MASTER 
FILES 


' N/A : . 


. : N/A -' 


TASK ID 


SAVE , 

^ 


mas^ter fil^ 
before/After' 
IMAGE On log 


j\IORMAL/ 
ABfdORMAL 


, P-T- 
TRANSACTION 

sN 


TASK ID ' 


COUNT & ADD 
TO/CONTROL 
((^OTALS 


master file 

RECORDS 
SELECTED frATA 
ELEJVIENTS 


. N/A 


D-f- 
• MASTER FILE 

VJ\I • . 
— ^— 



J D^DATE"§N=SERIAL# 

- f=TIME VN^VERSI0N# 
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TABLE 8:'SECURITY R-EQUIREMENTS DURING 
' > i OUTPUT OF DATA 



^ WnU 


ciiiupTiniy 
rUiMUJiUiM 


UfUAT 

^ WHAI 


C^^ATIIC 
blllf\IUb 


*n nil r 

time . 


> 

< 

TASK ID 

• , - ^; 


;i>l0RMAT ' 

SUMMARY 
^RECORDS POfli' 

TRANSACTION 
& MASTER 
FILE 10GS< . 

}■ 


RECORD 
COUNTS & 
^CONTROL 
TtXTALS 0^-~ 4 

selected' ' 

' DATA 
ELEMENTS 


\ 

N/A ^ 


D-T- 
SN-VN 


TACl// 
1 Adl\/ 

USER \{y 


REQUEST 

Ilk %0 mm %^ I 

WRITE/ 
UPDATE 


' FIVE ID 
DEVrCE ID 


SUCCESSFUL/ • 
UNStiCCESSFUL 
DEVICE STATUS 


* U-T 


TASK ID 


- WRITE/ 
UPDATE- 
IN-PLACE 

t 


DEVICE ID 
FILE ID 
FOR M'ACHINE 
OR VISUAL 
READ 


f 

complete/ 
incojvipLete 


D-T . " 


TASK llf 


WRITE 

r 


PERIODIC 
BACKUP FILE 


^ ^ 

" ' N/A 


D-T- 
SN-VN 



D=DATE SN=SERIAL # 
TrTIME VN=VERSION# 

V 
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B.lr2 Successful accesses. List all successful entries to determine 
- 'ufiage patterns . ' Compare successful ^ entr ies to. authorization table. 

8.1.3 'Jjoq- continuity check. Establish a' log continuity' check to 
determine v^en the syst^^did nofe" indicate 'that it- was in Use and check' 
against proceSsir^ schedule. All . unscheduled breaks in system activity 
Should be explained. . ' , < ^ . - ^. 



8.2 INPUT . . v.'"' , , ' ' 
Techniques 1, 2, 3 apply ^ shown in ACCESS. . . 

8.3 PROCESSING v ' ' 

Here a\ariety of techniques can be used to check processing 
intiegrity and security . ^ ' ^ \ ^ . ^ 

8X3.1 Manual Checking.' ManUaL checking of a selected set of previously 
processed transactions ^ be used to verify results produced in- aiv 
actual f |)reviou§ processing cycle. ' J- 

8.3.2 Control Itotals. Independent determiffe^ion of the control totals of 
Actual files by means of audit programs permit checking of totals 
against reported totals producejd by the sy^^tem. 

8. 3»3 Test Data. 'System test data can be used to produce control totals 
or -results that are ' * " * ' ' " . v . ^ 

case /'test decks )* 



or -results that are to be cljecked against predetermin'fed tot^s. (base 

8.3.4 Integrated Itest Facility. He're the auditor selects specia]^ 
transactions to be processed against auditor controlled file, segments or 
•records. This method is^used f^^ently to-iesL- selected processing 
paths of oji-line ptocessing/'systems. "Rxis may be done on a r-egular or 
unscheduled basis, and provides a deterrent to fraud since the ITF may 
be deigned to be transparent to prograimiing and operations -fjersonnel^ 
They woilld thus not be aware of ongoing security audit testing. 

8.3.5 Tagging. Tagged transactions (i*e. transactions to v^ich special 
codes have lieen assigned by- the auditor) can be traced ,through the 
processing of liye production runs, in* order to examine' intermediate 
pfrocessing results. . ^ ' - . * ^ 

8.3.6 Extended Record Maintenance. Extended record maintenance can be 
used to add and maintain transaction records within a master file, that, 
can be used to provide the processing history of a master file. In-line 
data collection provides sanples i3ata/ or stratification as an 
extension of the application program. 
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8,3.7 Tracing. Tracing can be used to document use of program module^, 
' or program instructions to process specific transactions. It is used to 
verify process logic and to identify unused portions of ccSnputer - ^ 
" programs. * * '"^ . ' 

a,J3#8 Ma^^ing., Use of program analyzers permits mapping of p^ll object ^ 

• program mtedules indluded in the load image library to determine, vrtiat 
, special conditions lead \o the execution of each program module. 

8.3^9 Reconpilation. Reconpiiation of the source^^tatemeht versi^on of ^ 
the program, and processing of the resultant object code ^against a. 
recent set of tr-ax;isactions can be done. A comparison of the two sets of 
results may lead ttJ evidence of. improper processing. % Additionally the 
current source progr^ can be recompiled with the resulting object f 
' ' module mechanically compared to the current pcqduction module Resident 

* in the library. This technique would' identify modifications to, the 
object module not reflected ir^ th'e source code. Once the source code 
logic has been proven, an auditor controlled' copy could, be maintained " 
for subsequent ccxnparison wi,th the production version to. detect prqgr^ 

modifications , ' . 

\ V * > 

8J3.I0 Parallel simulation. P^rall^l simulation programs using selected 
application logic, "'calculations and controls, relevant to spetific 
auditing tests can be used to reprocess selected actual transactions. ^ 
N Critical calculations can be verified by processing in another language. 
y • Dep^ding upan-^ystem complexiliy and the degree^'ofi flexibility^ ^ 

available, a ^generalized. software package could be used to parallel the 
opetatioi^€f a system. • . " 



8. 3. ^"^^ Retrieval Programs. Record retrieval programs can be used to , 
^lect transactions that either meet specified selection criteria, or 
are selected as a.xesult of statistical sampling criteria. .Printed, 
reports can^ be produced v^ich can be used for further analysis and , 
investigation.^ « ' , . 
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8.4 OUTPUT / • V • . - 

The following postprocessing techniques are used in checking 
system output. 

8.4.1- Output Listing. List the outputs and verify disposition of output, 
including schedule cc«npliance. ' . * - 

8.4.2 Authorization Listing. List authorizations (as in input) . - ^ 

Ofee post-processing techniques listed in the previous paragraphs ^ 
have been sumrparized and related to the security audit objective^* in 
Figure 3. It appears that fewer techniques are available for 
distribution control, recover ability and violation contrpl, than for 
6niqu^ness and integrity of transacti9ns and of processing. 
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9; NEEDED TECHNIQUES- 

. Techniques could be developed or iirprp^ed in two areas, ^kt^ge of 
logging security audit data, and analysis manipulation oSp^. logs'. 

,9.1 Logging methods 



Security of the se'cuttti^libg ^n^s'^dijDe .Established, .^curity 
data should be considet^tpf , %eryp,t'ion , i.e. passwords and critical ' 
logs should be prntiect^^-^fjoiil 'tu^ti access. 

.Security logs 'can be6^tablished using one or more of the followinq 
methods: ' 

' The siirplest m'etho(^_.vy!Dj3^d'be to use the present operating system 
software. This- would provide only minimal protection because it is . 
dependent on' the operating system and thd people who "control it .J 

A speciar^^pose-device, i.e. ^^ tanper proof, secure, recordilta 
microprocessor /'&GtuatedJ::^z--ep^^ instructions contained in all / 
.programs could also be used. Such a davice Would^ record all activity, \ 
including use of ^^pecial -control progr^ (e. g, "super-zap" that ' 
•normally leave no trace on the syst^ms^log. Similarly such a devke 
could record ail calls to program libraries, * 

^\ ; . , 

A conplete. hardware monitor similar to a cockpil 'flight recorder, 
with probes at critical control points throughout ,the system is another 
alternative. - It couM^ovide a complete security log, with a proper 
level of protection/independent of the system being monitored! • 

9^2 Software Ttools . <^ ^ , ^ , 

It was the consensus of the group that much can be done* with 
existing techniques, and that no new techniques needed to be developed. 

Existing audit software could be m^de easier to use, and degrees of 
iirprovement could be made. Also existence of software .capabilities needs^ 
.to be publicized,— many auditors do riot know "what" is available 
"where". ' , . * ^ ^ * 

- Available tools appear to be too cumbersome to use, and often are 
Iprimitive. For exanple, certain procedures de^ibed earlier, though 
having canmon objectives, generally reguire complicated programming, to 
accon5)lish their goals using today Is tools. Higher level software to 
•access litjgs. for audit purposes could be developed ► 

i:.' Eileijpnts in th^various tools are often not coordinated, e.g. 
tracing ^ ftiappin^C^^^ese techniques are generally appropriate to be 
used together, and r|cili^^s could be developed* so that they could JDe 
ijsed. together. • 
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10,' CONCLUSIONS AND 'recommendations:' 



Information should 'be published fo;: the benefit of auditors on 
"what"' audit tools are available "where", lhat is, a catalog of to6^s 
for security audit should be developed. This catalog would provide 
details of compoKients , ' and ^would be indexed according to' techniques, 
hardware, and software required to Use the tools. Conments ab^ut the 
level of .difficulty would also be included. * ' 

. ' Security log data should be built into new systems during their 
development. Security oriented personnel should paticipate in planning, 
development and design of systems', to insure auditabiHty. - 

• ' ^ I" - ' 

Secure logging hardware components should be explored, to provide 
tamper-proof recording capability for security audit purposes. 
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, \ ^ EDITORS' NOTE^/ '■ ^ ! 

A breif biography of the Session Chairperson follows: 

Dr. Hart J. Will has been- on the Faculty of Commerce and Bus'iness 
Administration at the University of Briti-sh Columbia since 1969, first 
as Assistant Professor and currently as Associate Professor of Account-' 
ing and Management Information Systems. H>s teaching and research in- 
terests lie in: MIS analysis, design . audit,' control and security ;^ da-, 
ta base management and administration; and audit software in general 
and ACL (Audit Coraraaod Language), in particular. He'has worked, con- 
sulted, taught, and published exte^isjvely. in .Europe and North Afnerica. 
His activities* inblude: Chairman of U.f.C. International Symposium 
on Computer Auditing^: Legal and Technicarissues, St. Augustin, Ger- 
many: 6MD, June 18-20, 1975 'and Editor o f Lega-1 and Technical Issues of 
Computer Auditing, the Conference Procei&dings; visiting Research Pro- 
sessor, Gesellschaft fuer Mathematik arid Datenverarbeitung (GMD) , St.- ^ 
Augustin, Germany 1974-75; founding chairman of an 'informal .DBMS Work^f*"" 
shop, 1976.-77; and currently Associate Editor of INFOR, Canadian Jour- 
nal of Operational Research and Information Processing 1977. His de- 
grees are; Diplom-Kaufmann (Free University Berl in) ,. Ph.D. (UniveVsity 
of Illinois at Urbatria-Champaign) . ^ ' 
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'The charge given to this session was: 

c 

' INTERACTIVE AUDIT TOOLS AND TECHNIQUES: What are the-iiiteractive 
audit too'ls and techniques available^or needed to permit on-line 
auditing of compiiter security? ! • , \ , 

The Institute of Interna.! Auditors considers internal audit a managerial 
control which functions by measuring and evaluating the effectiveness 

»pf other controls- It has become increasingly difficult in an ADP en- 
vironment for the auditor to fulfill. ttis>esponsibility in a* resport-;. vr 

• sive way and continue to audit on an after-th£-ract ba,sis. The speech' ", 
of processing alone requires a different approach. 

This session is to explore the audit tools and techniques that can be 

applied today and those that are needed^ tq bte developed which will per- 
•mit on-line evaluatiop of idata integrity! ' ' ^ « 

I, ^ • * 



' The concensus report that. follows was developed and reviewed by the 
entire- member?hip of this sessi'on. ' • • 
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Interactive cAudit Tools and Techniques 
A Group Concensus Report 

Hart J. Will and group members 



1. executive' SUMMARY- 



IJ Introduction . ' . ' L' 

l.T.'T Interactiveness ^ ^ 1 . 

.In an audit context, interactiveness is usually interpreted as on- 
line coding of audit programs, although the interactive audit prb^f^^mming 
featur'e is available only in relatively few systems. Another dimension 
of interactiveness is on-line audit processing in -a human-machine dia- 
logue in terms of free-format audit inve.stigations 3af a jcomputeriz-ed in- 
formation system.^ In regard to computer -security, some'use has been made 
Pt gathering on-line system, performance information (SMF, time-sharing 
session data, etc.) for purposes of near 'real -time monitoring and ccfntrol . 
Yet "in a comfi^er communications system whi-ch *is itself highly interactive 
and wher*e use"f data base tethnol^gy is predominant,, the requirements 
exist, for increased capability to use the computer., also as an inte/actiye 
audit' tool, 

1.1^2 * Research and Develapraent • * / . . 

. -There are many existing computer audit taols and techniques that are 
being used on a partially interactive basis. /interactiveness is cf^sir- ' 
abl^ *ih the development and maintenance of performance. The wQrking 
group believes that research and .development is needed with res^pect to 
true interactiye tools and techniques. TJie report includes some examples 
^of possibly areas for further study. 



1.1,3 Subject Areas 
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The following subjects are of' interest to the groyp:^ , 
-fnteractive^use.of existing 'audit tools and t-echniques to increase 
audit efficiency, y'^ ' 

-Development of pe^T tools and techniques in order to facilitate the - 
pelrformance assurance process in general, and auditing in particular. 

-Development and use of techniques 'to iricrease the auditability of 
computer s/stems! 

Summary ' ' ' • - - , 



1.2^.1 Performance Assurance . • ; ^ IH . 

* The summary framework js that of performance assurance, which is 
* ' • 12-3 
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defined as the^ assurance 'that a computer s/stem is performi'ng its intended 
functions wTbhin^a specified degree of accuracy, timeliness, and data se- 
Airity, ancHiheft it is no1;> performing unintended functions. Performance 
assurance i% the domain of several , different kinds of people aind. include 
the Certified Public Accountant, senior organizational manageirfent, inter- 
nal aucj^'tors, the quality 'assurahce function and operational management. 
Basic definitions and objectives are covered in sectiqn 2. Section 3 
describes the performance ^assurance function in terms of four activities: 
^ -Project "control objectives ' ^ / - 

-Information ^gathering. ' 

-Analysis and eva^^ua^n, ^ ' * • - , , 

• -Testing ^ , . • ^ 

1.2.2 Exis'tfjng Tools and Techniques \ \ 

E'xisting tools and. techniques that' can b^ used interactively;^ are 
discCissed /in section 4 A. • ' > . * ^ ^^"'^^ ^ 

'K2.3 Needed' Tools and Techniq'ues . \ - r 

Additional needed performance assurance tools and techni<}iies that ' 
should be. qui'te useful" in the detectio^ of malfumctions of systems pro- 
cedures or- control are discussed in section 5-. It^is possible to identi- 
fy symptoms 'r^el at ing to data or p.rogram errors, /anomalous activity, ac- 
^ cess control breaches and any activity that exceeds 'pre-determined thres- 
holds.' 'fhe following categories of tools measure these symptoms: 
-Near real-time error detection and correction. 
' - -Monitoring cif -•adequacy of cpntrdls. \ .^y 

^ -Measurement of design accuracy*. ' , " ' - [jf ' 

-Program modification control..' ' f; 
-Monitoring 'of system troubles or activi^^y^r — ^ < 

1.3 Use of Interactive Tools and Techniques ^ 

The working group has identified two' major categori^s/of uses for 
interactive computing. They- are interactive audit programming and inter- 
active audit processing. Xhese\are. defined in section 2. of the report. 
In the case of interacti.ve audi t^ programming, the behe^fts to the auditor 
in .developing his audit programs'are similar to the benefits in develop- 
. ing and debugging any computer 'prograrri. Interactive audit processing 
provides i.nteractlve e^ccess to report data/files and interactive execu- 
. tion of»an audit program'. 

J ^ ^ ' * ^ 

Integrative access to report data/files refers to the interrogation ' 

by the -audilcor of* report tiata/files which have been stored by the system 
controls an files for this purpose. Examples would Include frequency 
counts of various types of transactions on specific dafa ^*n attempts to 
penetrate security functions. . • 

' . f. • . ^ 

Jri'teractive executicyi of an agdit program refeif^ to the stepwise eo(- 
ecution of an audit program' providing the auditor th.e opportunity to ex- 
amine intermediate results in-line and base the next execution step *in 

' . * 12-4 
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'the program on ,thos6intermedjate results. 

The working group has concluded that interac^ve Itechniques for au- 
'dtting has not been wide spread.. The reasons identffiWd include: (1) 
Interactive audit programs are nqt^widely available '"-arid audi^tors are not 
accus.tomed t0 operating in this m^de. .(2) -Interactivi access to report 
data/files requires that controls be built into ^systems* to col.lect these 
data and to create the report files^. The nWded controls have not been^ 
Tormaliz^ed sufficiently to provide for extended auditabtl Ity, (3)' In-^ 
teractive execution of an audit pnogVp requires' new sortware design for 
the auditor to use. Few such processors exist and thoseUhat do exist 
have not received sufficient acceptance and exposure, \ 

1.4 Benefits of Interactive Tools and Techniques • 

A number of benefits can be derived from the use of ii^teractive 
tools and techniques to facilitate the performance assurance function. 
Since their cost effectiveness has not been fully exploVed,, further re- 
search and evaluation is warranted. ' \ \ 

Interactive tools and techniques facilitate the foc\Jsinb on system ^ 
or control functions in as much, detail as is needed (Zoortj \lense effect). 
They allow the reyiew of eVents in near real-time, throus(h^ontinuous up- 
dating of audit trails and recorded eVbnts. This provides th^-qapabil i ty 

to • • , • M 

V -Screen for file status conditions. - 

-Determine exception conditions, 
. -Summarize relevant .data or conditions, 

-Display unusual conditions. 

They may improve audit effectiveness by providing additional capa- 
bilities for determining characteristics and usage of controls. 

They may increase or improve the efficiency of audit by alloylf^ing 
more immediate return on audit effort. ^ 

They imprqve^timeliness of auditing through provision of immediate 
feedback and al'low corrective a'ction to occur without delay, thus* reduc-**^ 
ing exposures. ^ • ' > ^ 

Thefy reduce clerical effort an^^dit preparation and allow the Au- 
ditor to devote more time to professional effort and analysis, ; 

1 .5 ^ further D£liberation and Research . ^ . * ^ 

The group feels that further deliberations and research are required 
in the following areas: . " 

-Specification of design and performance i^equirements for interactive 
audit tools and techniques, • • ' - 

-Designs of interactive audit tools anjl 'tQchniques for interfaces 
' ( with operating systems and data base rrtanageitient systems, 

-Behavioral audit research to study audit behavior. in an jnteracti^re 



hunian-machine mode df operation, 

-Development of a comprehensive audi-t and control theory tp guide 
Performance Assurance (PA) professionals in thqir activ.ities and 
software designers* in^ the development of appropriate audit tools 

" and techniques. - ^ ' . ' 



2.1 . Goal 



2. . GOAL,, OBJECTIVES, DEFINITIONS * - 



* The development of an auditjvng approach for Ihe use of on-line or in- 

teractive techniques, to achieve performance assurance in computer systems. 

2^2' -Objectives * , * ^ \ " 

-Define the scope and requirements for interactive tools and tech^ 
niques. / . > • ^ 

-Review and define alien tabil ity and con.trol characteristics' ta.com- 
" ^ puter systems. ^ , ♦ ^ ' ' • 

-Describ? toels and techniques available^and specify rteeded'ohes. ' 
.f 'J ^-Develop criteria for the use of these tools in, specific systems ; ^ . 
e^.ir/)nments and defipe'tlie required interfaces (e.g. with Datal" 
Base, Opet'ating Systems). , ^ j < * ' 

» ^2.3 ^Definitions . • . . , 

2.*3fl -Performance Assurance ' * 

^ ^. . Assurance that a cojnputer system- is, performing its intended functions 
within a specified degree of accuracy, fimeliness, and data security; and 
that it'is not performing unintended functtons. The. level' of accuracy 
^ depends on the critical nature of the appl ications, and fil'e's '{master- 
. files > transactions and programs) as determined by managefment criteria. 

•2..3.2 Interactive Tools and Techniques, ' ^ . ^ 

, ' thsM-/ Tools and techniques that provi^de both interactive audit programming 
and interactive audit prScessing support. As such they •facil i tate immed- 
iate access to. or uses of live tiles (tnaster files, transactions and pro- 
grams) an^d to performance assurance data. This includes interactive ac- 
cess Jo application and control files as Veil as continuous dialogue be- 
tween human and computer systems, (See Figure 1,K^ \ \ • 

2.3.3 Interactive Audit Programming ' ^' ^ , \^ 

. The development of a computer audit program by means of a language, 
i,e. the auditor get^s immediate feedback ff'pm the language on syntactic, /, 
errors ^ncf preferably semantic errors as^well - such that the audit pro^^jrfw^ 
gram is instantaneoxisly debugged and ready for/mmediate (or deliberate- 
ly delved) test and/or e)^ecufion. Antonyms; 'generative (cqmplier- 
^ dependent) programming, host language programming.^ . ^ ^ 
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2.3.4 Interactive Audit' Pr6cessing 

Interactive, Audit Proces§fng performs immediate, ihter'pretive execu^ 
tion of computer audit program steps and whole au'cfit programs against on- 
line, files upon issuance' of simple, often termtnal -initiated command?. . / 
•Antonyms: Batch audit processing, .OfJ'-line file processing.- / 

2.3.5 Interactive Auditing . . - '\ ' . ' 

. . . 'J- ■ ' ' 

^ Interact! ve; auditing is dependent on interactive audit programming 
and interactive audit processing facilities as part 0/ a "self-^contained" 
audit software system which^can be interfaced' with client inforrnatton 
>-$ystems of diverse 'designs. • - ' ' * * . 

Antonyms: Batch auditinti. v * , 

''2.3,.6 Or^-Line Auditing , , ^ ^ ^ ^ 

' Refers to the capability to audtt'in an inte'facti ve jfl^er 
2,3-7 Auditing of On-Ljne Systems . " ^ ' . ' . ■ " 

Refers to the capability to"" audit ])oth^ the- systems themselves and 
their controls where the dominant mode d-f prpcessing is on-line (e.g., 
airline reservation systein, rea^l-time process contral , data entry systems, 
etc) ' • ^ / . . . ; 

2 A Performance Assurance Functions, * T - * ' ^ , 

2,4 J Model \ . ^' ' ' 

In order to. generalize the term ''a^uditing" tbe group decided to il- 
lustrate the previously de fined term "^performancetassurance functiojis" & 
as shown in figure 2. 
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2,4.2 CPA"runctidns"7 . '^.^ ' - % 

< To review, evaluate and test* an information^ system and Mts contents 
.<in performing an objective, independent examinltion in order to, express 
an opinion on financial statements. ^ \ 

fA*Z ' Internal Auditor Functions 

• • N ' 

*.To ensure that data is processed accurately and, that assets are be- 
ing properly safeguarded. 

iX^ Qual ity Assurance Functions 

To monitor and develop standards to insure efficien^t -and effective 
management and utilization of computer resources, ^ 

2.4.5 Operating and Line Management Functions ^ '^s^ 

J * ' . ' 

To provide continuing evaluation of the development and effective- 
ness of management controls and degree of compel iance therewith. Controls 
should be reviewed for: t ^ ' ' 

^-Effectiveness^ , ' - ^ ^ 

-Completeness , - - * 

-ConsisteYicy- ' ^ 

3. PERFORMANCE ASSURANCE ACTIVITIES • 
3.1 Introduction \^ ^ c - / 

The purpose of the performance assurance (PA) function, as previous- 
ly defined, is to determine that a computer system is performing its in- 
tended functions within^a specified degree of accuracy, timeliness, and 
data security, and that it is not performing unintended) functions. The- 
other part of .the definition mentions that the leviel of accuracy depends 
on the critical nature of the applications and data as determ'ined by man- ^ 
agement criteria, " ^ , ' * - 

In illustrating the activities^of the various groups^ involved with 
^the performance assurance function we dedided, for the purpo^se of our 
deliberations,^ to identif}iiithe following:*. 

-Setting PA objectives • * 

-Gathering ''information ^ 
• -Performing PA an^il^ses and fval uations 

-Jlfis^igning and performing PA.t6st pracedures. 

These activities are used in tfje next two sections for cross-class"^ 
ification purposes'^ with existing and needed PA t(5ols*and techniques^r* This*' 
way i\t becomes possible to illustrate how the varipus tools and techniques 
ean.be^^used by professionals involved in performance assurance activities. 
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3.2 Setting PAJlbjective's 

There are two types of objectives to be considered in performance 
assurance. The first type of objective relates to the nature and purpose 
of the pefformance assurance testing (audit or testing objectives). • The 
second "type of objective refers to the system to be tested. A system 
^ntrol objective or set' of objectives' are established as the basis or 
the framework to us€ in developing the 'system, procedures and controls 
for any- system elements {applications). The system contro-l objective^ 
desc^JJa* what- the system is to do, i.e., in effect, the goal to be accom- 
plished. The ot)jectives are.dej/eloped from criteria set forth by manage- 
ment "for that particular ar^. ' = ' 

A development teaiii, f9r^xample, in designing a systeft, in establish- 
ing tf}e detfiiled procedures, and in determining the type and extent of- 
intern'al controls to >e bui^t into the system, cari relate the procedures 
and particularly- the internal .control s back to the objectivesT 

In situations where system control objectives have been defined, they 
may be also useful to the performarite assurance group in evaluating th'e 
controls used in the specific system application. An end result of an>^ 
(Je^ign and implementation of a System, procedures and controls should in- 
clude a set of documentations detailing and describing the user and the 
computerized internal control techniques built into that particular ap- 
•plication. This "statement of internal control techniques" is extremely 
important to the performance assurance function and could be a standard 
■for all sySvtems. ^ ' ^ 

3.3 ^ Gathering Information . • ' 

The information .gathering phase of a performance ass-urance function 
can be described as the obtaining of all the necessary information and 
data' needed in order to review", to evaluate or to establisTi systems, pro- 
cedures, and controls. The material ^o be gathered includes, for example, 
"the statement of internal control techniques, detailed or summary docu- 
mentation*' narrative description^, of the systems and procedures, flow 
charts^ authorization -listings, and similar data. .If this type of infor- 
njation and data is not available, it becomes -necessary fqr the performance 
a'ssurance group to develop or prepare the material for- analysis and eval- 
^uation. Once the group performing the performance assurance function is 
required to create any or all of the data required, tha^ group" perfor/ns, 
in effect, functions that the systems development group -should ha^e per- 
-forined. The existejfice of the material described above is extremely im- 
portant to the peijfarmanoe assurance function and could be a standard for : 
all systems. ' . /' 

3.<J Performing PA Ana.lyses and Evaluations " 

'The analysTF^d eval uation'process culminates in the design and per- 
formance of tests with respect to |he systems, procedures and controls. 

These tests may iii turn, lead to further analysis- and evafuation. ' 

i \ . . ' 
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.Two factors influence the analysis 'and evaluation activities: the* 
critical nature (materiality and importance) as well as the complexity 
of the 'system appl ication. - Testing of an application becomes^- more exten- 
sive and more sophisticated when an application is critical and complex. 
In these situations, itxis important for the various groups involved in 
performance assurance to 'be aware of interactive ^tools and techniques ^ 
that are available for use\in on-lifie testing and in testing of on-line 
systems. With kjiowledge as to when and how they can be used. in the t^st-. 
ing process, audit programs can be prepared and executed interactively. 
The available flexibility allows as to focus the testing on important . 
corvtrol areas, on risk areas, and on the proper balance between compliance 
and substantive tests.- In addition, the test , programs can be prej^a**^^ 
to utilize non-interactive tools, and techn'iques where appropriate, ' 

3.5 Designing and' Performing PA Test Procedures 

o 

Based on the analysis and evaluation of the system, its' procedures 
and controls it becomes necessary to design and test the key controls 
that are being relied on. This activity can be performed in the follow- 
ing steps: 

'V-Select the verification technique. 

-Determine if computer assisted techniques will be used, 
* "Prepare and. perform the j:est procedures. 

-Review test results and determine if further tests are required. 

3.5.1 Select the Verification Techniques ^ ' • 

In general, two approaches can be applied in verifyij^g contrpls and * , 
processing: ^ - ' ^ ' ^ 

-Test af results: Select one or more key files or outputs of pro- - 
cessing and confirm the results. / 
-Test of processing: Per/orm specific t^sts of the ^ritical 
processes and controls directly. -t, ^ ^ 

3.5.1 .1 Test of Results ^ ' - / 

Verification and Resting of results is usually perf;ormed by.compar- 
bisons of results with independent files, organizations^ .or physical items 
or by reasonableness tests. ' Examples c^f the former'wduld be comparison ^ 
of computer records of personnel pay rates and inven^ry b^l^nces to in- 
dependent personnel department files and to 'physical/ inventory counts. 
Examples of the latter wpuld be tests of values 'witl^ expected ranges or 
comparisons with similar information*such as budgetjs and r^s^jlts of prior 
periods. , , « ^ 

3.5.1.2 Test of, Processing • * ^ 

Verification of processing involves ^ecific tools and techniques 
discussed in the next two sections to test\pecific^manual and computer 
controls and processing st^ps. For examplel the snapshot technique re- 
' suits in a list of each step of a computer program as if it is being pro- 
cessed and the status of key data elements as they are being, modified, 
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3.6.2 QetenfiJnTif'computer Assisted -l^ethDiques Will Be Used ' 

Use of the computer will depend on: t y ^ ' ' 

-The^nature of thp control. Supervising, for exampte/rs ^ control 
primarily testec^^ by observation^or by review K)f documented super- 
visory actions. Integrity tests of a 'data base m^ conversely, 
j^equirC;$he 'use of^rti computer. - ^ ' 
. -A\/yi lability of computer files and processing time^ 
, *-Cost justifications- " \ - ' 

^ -Computer skills to develop a computer program, if needed. 
* \> ' , ■ 

3.5.3 Prepare and Perform Test; Procedures 



Ihe preparing and performing of the test Vocedures are themselves 
subject to controls. . The controls must ensure that the programs and pro- 
cedures are designed to .achieve the desired test objectives and that the 
procedures and files are used as specified. Commonly, compliance and 
substanti've*tests are distinguished although they tend to overlap and the" 
same test may be applied both for th^e systems and for the data tests Ve- 
spectivcely. - . - 

Substantive auditing relates primarily to the^ financial statements^ 
as of the end of a fiscal year. Substantative- tests are .applie^ to the 
verification of dollar values and , financial balances Vather than the vef* 
ification of internal control. Their extent i's'governed by the reliance 
on'internal controls as det&rmiii6d by compliance tests. 

315.4 Rev'iew Test Result^ arrd Determine if further Tests Are Required 

This step is an analysis and evalua^tion function" to -'ensure, that the 
test restilts arb valid. Jt assumes that the test methodology, procedures 
' a?id results are documented for subsequent, independent Veview in a final 
-evaluation gf controls and related reliance and Exposure, \ ^ ^ 

The end^Ves^lt of performa-nce assurance is the determination whether 
fitAd^to what extent reliance fcarfi)^ placed'onjthe system and the results 
of system processing. While thfe' cdncj u'sions reached by -the. separate 
groups_may differ to some ^ext^n^T'th^ eac*h review the results of the 
testing to estimate sys'tern r^ iabtl ity in reaching their respective con- 
clusions. . ' 

- 4. EXISTING PERFpRMANCE ASSURANCE TOOLS AND. TECHNIQUES " • 

4.1 Introduction . % ' . * ' ' - 

In an attempt to review existing performance assurance (PA) tools 
and techniques iia the context of the previously identified PA functions, 
traditional^ batch and i*nteracti vb' too\s and techniques were identi^d<r 
■Separately .* These are summarized in Figure 3. ^ ^ ^ 

. ' ' . ^ ^ ^ r • 

On ea,Gh of , these, brief comments are ol^ered in terms of advantages^ 
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and disadvantages, 'afUhough no attempt is made to exhaust the classifica- 
tion possibilities. The major purpose of the exercise was to identify 
gaps for needed PA tools. and techniques that are discussed in section 5. 

** ' ' * ^ \ 

4.2 .Batch PA Tools and Techniques 

4.2;.! Utilily Programs • 

Programs provided by or acquired from hardware \6^ors and software 
companies to facilitate efficiency, utilization, monitoring and documen- 
tation. Becatjse of the vast number of these, a short list may suf1iic§ 
to illustrate the variety of these systems: 

-SMF'-lSystems Management Facility) . v 

-Automated Flaw^Xharting* Systems^ 

-Data Dictionaries, ^ - . 

-Program Dictionaries 

-Library Systems for data and progr^ams 
- . -HMBLISJ (utility to detect IBM 0/S modifications) 
^ -Comparison systems (source to 'object) 

a. Advanta,ges . > . ^- . 

1 . J^ay be available at no or low cost. - ^ 
Provides additional facts for auditors and allows the audi- 
tor to probe into computer systems beyondigi ,data fi^e and ^ 
transaction orientation. ^ . » 

b. \Di advantages . « . ^ . 
Way require additional technical experti,se, ' (i .e, operating 

^ systems, DBMS, etc.) ' \ ' 

2. ^ Not tested and implemented as "audit to6ls". 

4.2.2' Test Ddeks , . " . 

.Hypothetical transactions and work file records designed to test the 
controls and accuracy of program logic. 

' a. Advantages . ' ^ ' » ^ ^ - 

1. Provides. a highly specific test of individual control fea- 
tures and^ exception conditions . . ^ 
b. Disadvantages ' 

1. Difficult to develop and maintain test data. due to program 
modification. , . ^ . 
^ 2. Requires special com'puter runs^ unless a test module is avail 

able. ^ ' • . ^ * 

.3. Seldom cdmpr^herisive enough t^o provide ^n^adequate test Qf 
'reports and statistics. An auclit standard should be that 
teSt data fOiever posted to live files. 

4.2t3 Audit Modules , " ' ^ 

Special audit subroutines are sometimes contained. in application pro 
grams to perform specific auSit' functions such as an aging .of accounts 
or to eliminate the fmpagt of test data on the printed reports (see ITF 
an the following page). ^ . ^ " 

a . Advantages . ' ' , ^ . , ^ 
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• . 1. Provides for the execution of special audit tasks if required 

2. Can be "triggered" at any time. 
b, Disadvantaxies ' ' . • * ' ' ^ - , * 
. 1, Require expert programming and', depending on the design, 
--s-'pecial operciting procedures*. 

2. May be invoked by non-authoVized personnel; 

4.2.4 ITF (Integrated Testing Facility) 

Means of passing test transactions through a computer system simul- 
.taneously with live transactions without adversely affecting live>(iles 
or outputs. A. separate set of outputs, including statistics and reports, 
are produced for a^minicompany. This not only.ensures that the. test ma- 
terial does not ^interfere with any outputs concerning the real company, 
b\it aljo enables the auditor to .check that statis'tics a,nd reports are 
being prepared correctly. 

a. Advantages ^ " ' . . * 
1. Testing in a live environment routinely, 

2: No special running time required. 

3. No effect, on live records. • ; 

4. .Provides reports and sta*tistics. - \ 

b. Disadvantages 

1, Difficult to produce and maintain a complete set of Xest 
data, ' ' ' ^ ^ 

2, Requires special programming to integrate the test subsystem 
with the live system. 

4.2.5 Test Data Generator , , - ' 

A computer method to generate hypothetical transactions for testing 
purposes. ^ ^^^^r^. 

a. Advantages 

1, Automated development of test transactions and work file 
records, 

b\ Disadvantages ' , 

(See Test Decks) 

4;^, 6 Snapshot *^ - ^ 

Technique of capturing the status of data at a particular ;point in 
time of the^'^roducing cycle, e.g,, triggered by specific transaction types 
that are*<i^ntified by "tags" (tagging). 

a. Advantages 

,1. A good method for a very specific purpose, 

2. May r-educe "logging" requirements. 

b. ^ Disadvantages - ^ 

1, ReqLjires frequent monitoring by auditor' to avoid "overrtag- 
ging", 

2. May be too limited for general audit.appl ications and may 
affect proper "logging" procedures negatively, ♦ 



4,2.7 Tracing 
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A technique to 'identify the sequence^of actual exceptions of pro-. , 
gram code, triggered by specifictransaction types ^ identified by "tags" 
- on conditions (as Under Srtapshat) - , ' 

a.. A'dvantages ^^..^^ 
(as under. Snapshot) • . ' ' 

^ b. Disadvantages • • * 

. Jjias under Snapshot) 

4.2.8 SCARF (System, Control Audit Review File) . 

Incorporation of auditor - determined reasonableness tests into nor- 
mal data processing applications for the purpose, of tagging and/or ex- 
tracting, exceptional data into audit files. ■ 

a. . Advantaged ' " * . 

' . 1. Continuous exception reporting (see Audit Modules.) ) 

b. Disacfvantages ' 
1 . Processing tim§ 

4.2.9 Audit Software Packciges 

High-level, data processing languages to ^provide data access and " 
tomputational manipulations in addition to specific audi J: func4:ions such 
•as aging, confirmations; sampling-, etc.** The functions performed by the 
various software packages' are not^all^ equivcilent in terms of; 

-capabilities, i.e., computation, sampl ing," compares, etc. 

-interfacing, with d^ta -^ij-e. DBMS and, file structures); 

^-efficiency of execution I'i ,e. , running time\ auditor "preparation, 

tetc.) 

a. Advantages . ' * . 

1. Provides in-dependent data gath^ring'and analysis of data 
' files. , , ^ . , 

2. Improves efficiency of ^.auditor time and can assist in ex- 
panding the scope of audits. 

3. .Provides access ,to the entire universe' of data.' 

b. Disadvantages - ' 

1., Processing time can be longer than use of standard program- 
ming languages. V 

A standard should be, that all audi t software packages should be restricted 
to a read-only mode.' ' . ^ ' 

4.2:10 Parallel Simulation ' * 

It is a mea^ns of testing computer application processip^ by us^ing 
the same inpuf data and files as the application systems and attempting, 
to produce the same results-. The simulcjtion resuHs are compared to. 
"live" results confirming the results of computer applications^proces^ing 
or identifying areas of descrepancies for further analysis. 

a. :>;^dvantages ' ' \_ / 

-^1, Compliance testing of application programs can be performed 
with live data without jeopardizing files. 
8. Application program functions tested can be analyzed pri- 
marily through non-technical user documentation (e)^ror and 
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balancing procedures). 
Disadvantages ' * 

_1 • Requires good knowledge of functions performed. 
2;- Time required to develop simulation program. 

4.3 ' Interactive PA Tools and Techniques© 

The group identified two interactive audit tools avail abjj^ja date 
and suggests that tHese.be furthfer studied. and evaluated.^ We^TW 
followefd two adgiitional leads to what were supposedly other existing . 
' interactive audit tools, but theseproved to be unsuccessful. 

4.3.1 ACL (Audit Command Language)*. ^ ^ ' * • 

ACL is available in twQ versions at the University^ of B.C. in Van- 
couver, B.C.^ The first is running under the Michigan Terminal System 
(MTS Operatiilg System) and is us^ extensively in 'teaching (both academic 
and professional through CICA) anjf research*- Jhe IBM version runs under 
the IBM/OS/VSl system and is us^d internal and external auditors as 
well as consultants. As- the first fully interactive audit language, ACL 
* represents a pioneering effoVt to combine £he various performance assur- 
^ance functions into a single professional Qser language, 

4.3.2 NA'ARS (National* Automated Accounting^ Research System) 

NAAR5 has been developed jointly by the AICPA and Mead Data Central, 
Inc/ It is possible to search interactively (through a'ciimputer terminal) 
the .full text off the financial statements, ^fpotnates and auditor reports 
from the published annual reports to shareholders of over 3,500' companies . 
Other files accessible are various AICPA publications as well, as federal 
securities law and federal trade regulations. * 

5.' NEEDEDIPERFORMANCE ASSURANCE TOOLS AND TECHNIQUES ' ^ 

5.1 . Introduction * 



The mentioned performance assurance (PA) tools and techniques that 
are in existence to date are, in many cases., quite useful i,n an auditing 
situation. However, these tools are in many instances little utilized 
by both auditors and quality assurance personnel ./ Their potential may 
beoinknown, or their appl icabil ity ^to performance assurance may not be' 
obviaus. In some instances the tools are designed for another purpose 
''(e.g". hardware or software/ionitor^) and thfeir applicability to security 
or performance assurance i's not/ intuitively; obvious . 

The fol lowing subsection describes anct explains categories of needed 
tool s,anif^ specifies >equirementsr for their 'design and development- 



id 



' ' 12-16 



.ERIC " , ' / ' • 23G 



5.2 Needed Tools and Techniques 

> ' ^ * 

The' tools and techniques described below can be utilized' in two ma- 
jor areas,." Detection of malfunctions or inadequacies, jof systems, proce- 
dures, or .control s,^n be accomplished interactively throygh jnonitoring, 
trace or te^t fa^ities. It i^ also possible to measure the "health" 
of a-system looking for symptoms such as excessive errors ^ anomalous ^c- 
cess^to a sensitive file or excessive changes to a given program. This 
is analogous to the tests, probes and data gathering performed by the 
medical pro.fession to diagnoses disease and requires analogous j.udgments 
.by PA professionals. - * * . : 

- 5.2.1 Near* Real -time Error Detection and Correjction' • " ^ 

The tools in this category a^e useful in detecting and when practi- 
cal, correcting errors in computer syStdms-as they occur before any"dam- ^^.^ 
age"'' has occurred. Examples of damage include the incorrect automatic * \ ' 
disbursement of large*amounts of funds in a funds disbursing system or 
false feedback in a process control system. These controls are oriented, 
to the operational system "in the whole". It is assumed that the hardware^^^;-^ . . 
and "individual system modules have alteady been tested and verified, but ""-"^ _ 
that failures may qccur wh'^the' various subsj/stems are operating together '^f^^'r^ 
as a larger system.' - We subirrhxthat th^ following tools are needed: ^c^: 
- Interface Data Monitoring and Testing - routined that exist to test v ^ 
. data at each interface between mo'dules in a system in terms of range,^ -^'^^^t^ 
V * Jimits, and validity of fields. ^ 

- Threshold Detection - hardware and software monitors to in^sure var- 
P iant and invariant characteristics of systems to detect and imijiedi-^ . 

ately abort in cases of unusual usage' patterns . 

' ' '* . . ^ • 

5.2.2 MonTtoring,Sf Adequacy of. ep'ntrols , , ^ 

The tools in this category provide for the ori-line testing of. the 
' predetermined and specified controls that have been buill: into the sys- 
tem.' They pe^mit the auditoY to perform tests on the operational system 
to detect potential trouble spots. \ We .submit that the, following tools 
are needed: \ - ♦ 

- Software Beha^vior Monitoring -\these routines- would exist in a^dor,- 
mant state in a system and jwherl invoked by^^in auditor wouTd begin 
monitoring, the behavior of specT<Q<^d software modules* in terms of 
accesses, , inputs, outputs, and fr^uency of usage. >^ 
- Configuration Auditing - through access to this routine, the audi- 
tor-can irfstantly get information on the current configuration pf i 
the operational system for particular use in -large teleprocessing ' 
' systems-.' " . 1^ 

- Interactive Tracing - routines similar to generalized debug packages 
can allow an auditor to step through the operational cycle of a sys- 
tem, monitoring both changing data values and synchronization of ^ 
' events, and making modifications to data, values to verify the ade- 
quacy of controls at the module *interf aces . • 

- Artificial Load Generators - routines 'to permit the- audjtor to gen- * 
era-te controlled amounts of transactions and input data* to test the 
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system' under varyjng^condi tions of loading, / 

. 5.2.3 _Me?iSiuiement of Design Accuracy 
■ . ' * \ 

In "this section we address stools and techniques for specifying and 
documenting systems and cgntrol.s. It is^possible to verify system speci- 
• fications against -functional require^ments for systems as well as system 
control s, \ - » • . 

♦ ' •• ' , , " • " , 

We submit that the following tools are needed: 

•^qui rehients Specif ication Languages - computer languag'es for' spe- 
cifying system requirements to permit -verification against functioV 
aT requiremejTte/ ' 

-Control. Feat#g Speci fications - formal methods for prd^grammers to 
document ^control features such that auditors can "easily" "understand 
^ • their applications,, functio^^, and anticipated performance. ' 

'5.2.4 Ingram Modification Control _ ' ' . 

The tool's in this ca-tegoo' would permit the auditor to verify the 
adequacy of the procedures for controlling p/o^ranr modifications through 
on-line testing. v,,. ' ' , ^ 

♦ > ^ . - 

We recomrperKi the following to,ols: ' 
, -Program Mo dification Detection -.check sums and similar routines 
can be used to detect modification of systems, applications and 
•- , . control -software. 

-Program (M odification) Audit Jrails through interrogating a par- 
ticular on-line file the auditor coufd»get compiefe information on 
every program. In addition,'. it sfjould be possiijle.to "recognize 
' - -changes to a par,^ular program, including who madg each change, 

' ' , ' . ""^ mad^TIthe^oblem that "caused the ^change, and when the 

modified program betame operational*. ■ < 

5,2.5 'Monitoring System Trouble Indicators ' . • 

* - "^^^ 1"" this category would permit >an auditor to interrogate / 

■• . tiles containfng information 6n the e^ecutiortlof and,systeCcontrol of*/ 
various security features". The recommended needed tools a^i^: 
. -Utilization Frequenc y Monitoring - provides frequency information, 
on-lin^e, -concerning^accesses to any privil edged' module,' device, 
• ■ -'data^ and transaction,.- ' • , 

' , ' " Utilization- of ContTo! and Security Features - interrogation of this 

; ( . ,file would allow an auditor to obtain infgrmatfon on the;utiliza- 
tion of any security, control ,• error detection,^ gr error correction 
feature inthe system including frequency of usage and results of 
execution; an eXfimple would be i nformation 'on data before and after* 
execution of an automatic errpr detection feature. ' 
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Figure 4 suirparizesithe tools and techniques we feel are needed to 
fulfill 'the various performance assurance functions. A separate column 
"control" was added to indicate that some of these tools and techniques 
may also be used (already) for internal control purposes. .^Auditors . 
shoyld'be aware of. them to recognize their potential' benefit:' in the. in- 
formation gathering function. in particular." 
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6 . 

Introduction 



SUMMARY AND mOMMENDED FOLLOWUP 



This final section provides t)Oth a brief and general summary of the 
recognized need for interactive audit tools and techniques and offers^ a 
,few recommendations for appropriate foll^up on the* subject.. - 

^ ■ . , ' ' ^ *' 

6,2 .Need for Interactl^fe^Tools and'Techniqlies * ' ■ * 

In spite of the apparent lack of* a?wa.reness of interafctive tools^and 
techniques for perfofmance assu;^ance fufictipns, the group recognizes' the 
need for such* tools and tries to summarize Jtheif benefits in the execu- 
tive summary (see^section 1.4). ' ^'^^ *> " a, ' 

The existing tools listed in section 4.3 deserve the attention of 
all professionals working in the performance assurarlte ffeld ar\d should 
be discussed and' studied in greater depth . and d/etail. 

In identifying needed tools an(\ techniques (see section. 5) the group. 



tri&s to broaden the outlook of all PA professionals and^hopes to stimu- 
lateyfurther discussion both on the auditability of modern information 
systems anij on the ways for performing comprehensive PA atidits. 

6.3 Recommended Follov^up 

The .group feels that further deliberation and research is required.. 
We would* like to pursue the following topics as early as possible and ask 
for support to discuss them: ^ ^ ' - ^ * ' v 

-Design sriteria for in^eracti ve/PA tools and techniques. 
'•Interface designs of interacti^Ve PA tools art<l techniques with oper- 
ating systems (OS) and data ba'se management 'systems /dB1*IS). 
-BehavioraJ audit research to study interactive human-madtiine>ehav- 
ior'in tfie context of performance assurance. 

-Development 'of a comprehensive audit and control ^theory to guide 
PA professionals in their work and software designers in the envel- 
opment of PA tools and techniques. 

'"^ ' ' ' ^ . 

6.3.1 .Design Criteria ^ , ' 

Since a few. interactive PA -tools^nd techniques , exist, it is possible 
to consider them as prototypes which deserve further study and evaluation 
by the large number of professionals acti)(e in the*- perfprmance assurance 
field. It^may be possible to adopt some of the existing topis oK become 
•feasible to specify design and performance requiremertts ^for future sys- ^ 
^tems/; > * " • , •* 

6.3.2 Interfaces \^ 

All .^n1^1e^crtVe PA tools 'and techniques require an interface wfth the 
'opera tigf^jstj^s^js^^ of theb will require an i,nterface with the sys- 

tem perfbtWing'da^^ management functions. Yet, hardly any PA pro- 

fessional is.ip^^^^On the-design and standardization of OS and DBMS."^ 
'Diffferences iVf15S'^£nc!^ DBMS or inherent weaknesses of any one of these 
may'make the "^inter^ifcing PA and audit "functions inefficient or ■ 
ineffectij^.^N^thfe^groap therefore urges all professionals to recognize 
the aeed'I'or feasible interface designs and urges them to get involved 
in deliberations concerning these important interfaces. 

^.3.3 'Behavioral Research . ' , ' . ^ 

Behavioral research is needed to determine which audit, software 
functions are valuab.le as interactive -features. Since ajjdit requirements 
vary with projects and with time,*some interactive tools may be relevant 
-Only in certain irfttances. Furthermore, under certain conditions the V 
•audit td^ol used may, have* an effect on the procedure and^also on the con- 
clusion&< feaciied by the auditors. It is therefore necessary °to recog- . 
nize that the audit approach may be dependent on the tppl used, and vicfi, * 
Yer$a . PA 'functions may become much (Busier 'or much more <iifficuTt, un- 
less the .iTi'terpfay between auditors and their tools' is recognized <ind 
studied-in consi(ierably more depth- than was so far possible. 
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6.3/4 ^ Theory / " - ♦ . 

^ It has beccme. feasible to develop a comprehefisive audit and control 
theory, for the pCTformance. assurance functions, bepause it is now possir" 
b]e to monitor interactive human-machine beh^w^ior in the PA context. . * 
Consequently, it, will .be possible to^guide PA professionals in their 
tasks and to develop "intelligent" PA tools and techniques, thus making 
the performance of the various PA functions covered in this report more 
and more convenient and effective. - ' 

■■ ■ Y ■ 
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•APPENDIX A! WORKSHOP ATll^NDEE LIST 



This appendi5('l1sfs the Workshop attendees alphabet! ca;lj^? The 
gen^fl format^of a listing is as follows mph the* square brackets in- 
jdicafing the location of the various pieces of informatton. 









• < 

Line I: 


Name 





Workshop Role 
in addition to 



Line 2: 



Line 3: 
Line 4,5,. : [Address J 



tOob Title and/or Office .Title, if known]* 

*v - — ' - 

[Name of Organization] • 



/Part of ProceedingsN 
Vcontributed to / 
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EDP Audit Controls 

7700 Edgewater Drive, Suite 325 

Oajcland, Californias, 94621 
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1211 Avenue of the Americas' 
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n: D. Babic (l\X). 
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.Partner" 

Sei^man & Seidman • 
1200 1 8th Street, *N,W. 
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■ Staff Assistant 
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and Technology ' . ^/ 
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Washington^ D?G, 20234 
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The MITRE Corporation 
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Supervisor 

Ernst & Ernst 
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Howard R. Da via (III) , ^ 
Director of the Office of Audit 
General Services Administration 
19th &'F Streets,. N.W. 
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' Defense Audit Service 
Room 624, Lynn Building 
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Suite 
90071 



2700 
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.Bank of America (8-900) 
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(V) 



941p 
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IBM Corporation" 
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1133 Westchester Avenue 
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Donald L. £irich (V) . 
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iT, S, General Accounting O'ffice 
4fl'G Street, N. W., Rm, 5814^ 
Washington, D. C/ 20548 

Jerry FitzGerald, Chairman (X) 
Management Systems Consultant ' 
Information Systems* Management 

Department 
Stanford Research Institute 
MenlQ Park, California 94025 
and currently w^h: 
Jerry FitzGeral^ & Associates* 
Management Consulting . 
506 Barkentine Lane - 
'Redwood City, California * 94065 



\ 



A-2 244 



Thomas Fitzgerald {M^ , 
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525 Market Street - ^ 

San Francisco, California* 94105 

Malcolm Blake Greenlee, .Chairman 
Assistant Vice President 
J?omptroller Division, WOS 
^F-31,.T-20 
Citibank 

20 Exchange 'Place ' ^ 

New York, New York ^10005 

Peter'D.-Gros6 (VI) * 
Computer Sciences Corporation 
6565 Arlington Boulevard 
" Falls Church,^ Virginia 22046 



Stuart W, Katzke, Recorder (IX), 

Systems Architecture Section 

Systems & Software Division, I GST 

National Bureau of Standards 

Washington, D.C. 20234 
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Walter Keanevan (IV) . 
Directo'T', MIS Program 
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College of Poblic Affairs 
American University 
Washington, D.C. 20016 

Kathleen Kolos ," Recorder (IV) ■ 
(V) CIA 
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4 Washington, D.C. 20505 • 

Leonard L Krauss, ChaiTrnatTTiX) 
Manager, Management? Consulting 
Service 

Ernst & Ernst . . ^ ^ 
140 Broadway 
' New York, Mew York J 0005 



Thomas !!• Hamilton CVUv ^ ^ ^ 
Xorpor^e "Systems 'Devel ojMnent & 

■ Administrative Services Division 

Eastman Kodak. Company 
-* Rochester, ^N^w York 14650- r ^ 
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♦Director,' Computer Sci^ces 
^^Sperry UNI VAC Corapiuter-^y^teins 

2121 Wisconsin Aveniie, N,W^ 

Washington, D,C- *20007 

^ Robert V, Jacobspn, Coordinator 
A&sjstant V'ice President 
Chemical Bank ^ 
55 Water Street 
New Yark, New York 10041 

S'..Jeffery, Host (I, III) 

Ctiief, Systems & Software Division 

Institute for Computer Sciences 

and technology \ . 

National Bureau of Standards 
Washington i d.C 20??4 



, rjewjfo 

Milton^Lieberman, (x) ^ 
Group Manager^ 

Merrill, Lynch, Pierce, Fenner & 

Smith, -InCi 
165 Broadway 

New York, New York 10006 

* . ' '* . 

Fr^d L Lilly (III) 
Lilly's Harris, CPA 
^1113 Williamson. Building^ 
Cleveland, Ohfo^ 44114 

Theodore. A, Linden, Recorder (VI^lV^ 
Systems Architecture Section 
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* National Bureau of Standards 
Washington, d.Cr 20234 % 
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Section 
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National Bureau of Standards 
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IBM Gorppration , • 

1"501 California Avenue 
. Palo /^Ito, California 94394 

^Aile^en MacGaha^ (IX) ; 
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'€hase Manhattan Bank 

1 Chase Pla?a -^21st Floor 
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.W. Gregory McCormack IMVII) 
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APPENDIX B: EVOLUTION OF THE WORKSHOP AND PROCEEDINGS 
1, INITIATING THE WORKSHOP 



The National Bureau Of Standards Itnitiated Task Group 15^ (TGi.15) 
within the Federal Information Processing Standards (FIPS,) progr^ in 
,1973 to develop standards in Computer Systems Security, TG-15, chaired 
by, Dennis K. Branstad of NBS, was composed of representatives from* 
private industry as well as Federal, State and local governments. In 
March of 1976 an informal task team on Guidelines* for Computer Security 
Auditing was formed within TG-15. It was chaired by Robert G, McKenzie 
of the General Accounting Office ancj^had Zella CJ, Ruthberg as the NBS 
liaison person. Its mission was to be two-fold: lj to convene a 
workshop on* security auditing that would consolidate the state-of-the-- 
art 'information available in the field 'and define areas for future 
research and 2) to adapt. this information to the needs of* Federal agen- 
cies dn the form of ^Federal .Information Processing Guidelines, The In- 
vitational Workshop on Audit^nd Evaluation of Computer Se5urj:ity, which 
took place pn March 22-2U,1977 in Miami Beach, Flor^-da, accomplished the 
first of t^hese two tasks. Since TG-15 wds terminated as a formalv com- 
mittee in the Spring -of this year, the second task is expected to be |cc- 
complished by a working group convened for this purpose and will result 
ih a FIPS Guideline publication by the Nat4.onal Bureau of Standards, *' 



^ 



' , 2, PLANNING THE WORKSHOP 

Under Robert McKenzJ.e.'s direction and Zella Ruthberg »s assistance, 
the TG-15 task team worked on developing what was hoped would be a pro- 
fluctive format and a comprehensive set of topics for the workshop. It' 
Was an. informal group consisting of P.eter S, Browne of Computer Resource 
fcontrols, Adolph Cecula of the U,S, Geological Survey, Robert H, Court.-*- 
hey of IBM, Fnapk Drefs of HEW, Robert V, Jacobson of Chemical Bank, 
, iJohn Panagocos of Equitable Life, and H^rry Robinson of Metropolitan 
Life,,- Inputs on possible topics were contributed by\the task team 
jdembers as well as requested and received from William E, Perry of the 
Institute of Internal Auditors, Robert l'. Stone of the American Insti- 
We of Certified Publfic Accountants, arid Keith Dorricott of Jthe Canadi- 
an Institute of Chartered Accountants, 




2.1 Workshop Forsjat 



The njrinat decided upon waa a relatively small invitational topic- 
area workshop that would cover ten major' areas of 'concern in computer ' 
■ security audit. Each topic would be h^dl'ed'by an interdisciplinary' 
^gr(>up of not more than ten individuals. It would, be chaired by a recog- 
nized authority in that area and staffed with a broad range of experts* 
mainly selected by its chairman. A concerted effort would be made to 
obtain representation from .both the aud'it and computer communities. 'The 
Job of Recorder fi^the various- sessions „was assigned to task "team 
members and NBS.pe&ple. During the Workshop the Recorders were respon- 
sible for capturing and. distributing in printed form, major j^deas 
developed in their sessions. Some Recorders^ by mutual agreement, did * 
much more than that. A few task team members 'were to be session coordi- 
. nators as well as provide a pool of back-up attendees for last miqute 
drop-outs. Robert. McKenzie was to be the General Chairman" and Zella 
Ruthberg the General Vice Chairman. This last arrangement provided the 
vehicle for the excellent support given this* workshop by both.GAO and 
ms. . ... ' i . 

^ • Eath .session was to spend over two days developing a pisition paper 
on their topic. If no consensus could be reached a majority and minori- 
ty report was requested. The last af;ternoon was ^ set aside for the 
presentation of conclusibns, by the. chairman of each session.* The • 
results of these discussions would be published by NBS in a Proceedings. 
It should be noted that this format was pat^terned after the highly suc- 
p^ss^^ NBS Workshop pn^ Data Base Directions held .in October of 1975-.,. 

>• * ^ . . ^ ' * * ' / 

2.2 .Workshop Topics and Chairmen /' - . * ' 



It' was recognizea that no set of topics coujd be selected to cover 
the mairv areas of the subject and also be mutually exclusive.* T^here^ 
would be unavoidable overlapping wi'th any set of t'opics; Tfie acfbal. to- 
pic selections by the task team were ultimately made from the point of 
^view of covering the major considerations in any computer security au- 



The topic areas and the selected chairmen were as follows: 



INTERNAL AUDIT STANDARD^ William E. Perry 4 

k • * ' Institute of Internal Auditors 

QUALIFICATIONS AND TRAINING C* 0.' Smith 

*^ . • , . •Ui ,'S. General Accounting ^Office 

S^lCURm ADMINISTR^ON^...^.;,...Blake Greenlee 
I. V ^ . . ' Citibank * ' ' . 

'AUDIT CONSIDERATIONS IN VARIOlTS 

SYSTEM ENVIRONMENTS C^rl Hammer . '/J 

. Univac T 
'ADMINISTRATIVE AND PHYSICAL * ^ 



CONTROLS W. H. 'Murray' ^ 

' IBM\ ■ 

PRQBRAM/INTEGRITY Clark Weissman • ^ ' 

' * . Systei& Development Corporation 

DATA INTEGRITY.^ .'.Leonard I. Krauss 

Ernst Er:nst 

COMMUNiaATIONS .Jerry FitzGerald 

^ . ^ Stanford Research Institute 

POST-PROCESSING AUDIT TOOLS ^ * . 

•AND TECHNIflUES .....Richard D. -Webb ' ^ ^ 

' Tpuche Ross & Cd. 

INTERACTIVE AUDIT TOOLS AND . ' ' » 

TECHNIQUES Hart J. Will 

University of British Columbia 



A 

V • 



2.3' Pre-Workshop Session Activities 

^" Each chairman, with guidance from .the General 'Chairman and Vice- , 
, Chairman, then procee"ded to fill his session with a balance of incJividu- 
als from the audit and computer communities. A more elaborate .d^scripr 
tion was written for each of the session topics and distributed to all 
p'rospective participants ):o enable them^to come to. the workshop with'a 

- -clearer ic^ea of the subjecft- of their session. Session chairmen were * 
asked to request and distribute pre-workshop position.^ta-tements from 
their participants* in order to stimulate their group to -formulate some 
of their ideas prior to the workshop. Many participants prepared sach 
pre-workshop statement-B ^o that in genenal the convenecl sessions were 
a^le to progress very rapidly. Each ses§ioji. chairman was given, complete 
.freedom to' structure his session in any way he felt might be productive": 
'This proved to be a useful tactic since it gave each chairman and his 
.a^ttendees the latitude of beting- able to operate in a manner they were 

^**-most comfortable with. v 



3. AT THE WORKSHOP 



After the keynote address had ^set the stage for the activities of 
^^his Workshop, 'the individual sessions each met separately for'two and' 
one Jialf days to develop their thoughts on each, of their topics. Each* 
session had a Chairman; a Recorder, and four to eight attende,es» They; 
* were supplied wi'th a folder for each, containing a copy, of FIP? I^UB 39^ 
("A Glossary of. Termiaplogy for Computer Systems Security"), the Canadi- 
an Treasury Board Guide on EDP Administration entitled "Security in an 
EDP Environment," plus various writing materials to -make things con- 
venient. The Workshop offlcef^at^ the meeting site supplied the sessions 
^^with continuous typing and xerox services to expedite matters. On the 
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last afternoon of this. three-day effort the attendees again met as a 
single group and each session reported its findings. At th^ end of the 
Workshop eight of the sessions submitted a rough draft of their report 
.and two submit t^d^ detailed outlines, I* 



4, T^E SESSION REPORTS 

The sess|.on attendees were g^ven a^. great ^ d^al- of latitude. in pro- 
ducing their session reports /with the resutt^ that no two reports were 
prodt»ed>in exactly the same way. In some cases 'the writing of , the re- J 
port was divided among all %he attendees at that .session. In other 
ckses an individual or a ,sinall' group froto the session wrote the repc^^. 
In most cases the written report was reviewed by. all the members of the 
session. Although the ^attendees of each. session were given the option 
of producing a majority and minority report, all .groups pr.oduced only 
consenj^Us reports, .3 ' 

In presenting the .reports in 'these Proceedings, the Editors intro- 
duced an Editors' Note ^t the beginning of each report, Jhis contains 
brief biography of the session Chairman and ^ statement 'of the complete 
charge given .to that session. Included at the end of this Editors' ^iote 
is a brief statement concerning the manner in which that report was pro 
duced, >^ 
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